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Prólogo 


El objetivo de este libro es simple: salvar el vacío entre la programación y 
la ejecución de juegos. Este libro trata de ayudar a los aficionados a los 
juegos a hacerse mejores programadores y de ayudar a los programadores 
a diseñar mejor los juegos. 

En el libro se progresa a través de todas las etapas de diseño y de 
codificación de un juego, desde la formulación de las ideas a la depura- 
ción. Al mismo tiempo, aspira a servir de ayuda a los principiantes en la 
programación a familiarizarse con muchos de los conceptos que, aunque 
fáciles de comprender, suelen hacerse farragosos por una jerga abrumado- 
ra con términos tales como “programación modular”, “acceso aleatorio”, 
“comprobación de errores”, ““manipulación de ficheros” e “inteligencia 
artificial”. Los términos se emplean como un jugador podría necesitarles, 
y no como un código misterioso comprensible solamente para personas 
expertas en actividades de computadoras. 

Este libro está concebido para el programador principiante que acaba 
de adquirir los conocimientos fundamentales sobre el BASIC y que ahora 
desea saber lo que hacer con estos conocimientos y cómo proceder a la 
elaboración de un programa importante. Con el empleo del juego de 
aventuras con su tema principal y el Spectrum como su microcomputado- 
ra más importante, examina todos los ingredientes de buenos juegos, 
incluyendo la estructura, visualización, originalidad, carácter atractivo y 
lógica. Sea, o no sea, su microcomputadora un Spectrum, si estuviera 
interesado con los juegos, encontrará un gran número de estrategias y 
recomendaciones para programar juegos en cualquier microcomputadora. 
Esté, o no, interesado por los juegos de aventuras, encontrará muchos de 
los principios aquí tratados y que se utilizan en la concepción de otras 
clases de juegos. 

A medida que avance a través del libro tomará parte en diseño de dos 
aventuras completas, estando ambas completamente listadas y documen- 
tadas, así como en veinticinco rutinas de juegos. En aquellos casos en que 
se puedan explotar las características útiles del Spectrum, estas últimas 
son objeto de descripción, pero se ha tenido cuidado en detallar algunas de 
las diferencias principales entre el Spectrum y otras microcomputadoras 
para poder efectuar una adaptación más fácil de las rutinas a otros 
sistemas. 

Si posee un Spectrum o quiere escribir un juego de aventuras, éste es el 
libro que necesita. El procedimiento de las órdenes verbales, la construc- 
ción de mapas, el diseño de enigmas, el almacenamiento de datos, la 
definición de gráficos, programas “inteligentes”, variables de monstruos y 
protagonistas, construcción de trazados, control de movimientos y mu- 
chas ideas concretas para aventuras se incluyen en su totalidad, junto con 


IX 


muchas rutinas en Spectrum BASIC para su incorporación en sus propios 
juegos. En particular, varias características del Spectrum BASIC que no 
están bien documentadas en otras partes se utilizan en este libro para 
desarrollar su conocimiento del lenguaje. 

He de expresar mi agradecimiento a Carrol, Kay y Owen que prestaron 
su ayuda en la preparación de este libro con sus propias aportaciones 
personales y a Mike Costello de The War Machine para su permiso de 
reproducción del Generador de Nombres del Capítulo 7. 


UNA INTRODUCCION 
A LAS AVENTURAS 


Imagínese que está en un túnel verde con paredes húmedas. En el suelo ve: 


un pergamino 
una caja de ébano 


¿Qué hará? 
* COJE LA CAJA 


De repente, un gnomo lleno de arrugas sale saltando de una grieta en la 
pared. “¿Quiere robar mis esmeraldas?” grita y levanta amenazante una 
gruesa porra de bronce. Usted quiere: 


1. CORRER 

2. HACER FRENTE Y LUCHAR 
3. HABLAR PARA DISUADIRLE 
4. SONREIR DULCEMENTE 


* SONREIR DULCEMENTE 


Usted opta por sonreír dulcemente. El gnomo sonríe también mientras 
retira su porra de encima de su cabeza. 


Este es un encuentro que podría tener en cualquier juego de aventuras. 
La aventura podría ser un juego de tablero, un juego de sobremesa con 
miniaturas, un juego de lápiz y papel o un microjuego. Los juegos de 
aventuras se presentan en muchas formas y magnitudes y se juegan de 
muchas maneras. Casi todas las microcomputadoras tienen, como míni- 
mo, una aventura escrita para ellas y las unidades centrales de muchas de 
ellas, en un centro de enseñanza o en un negocio, tienen su monstruo de 
softvare particular o solamente una simple aventura. 

Este libro le indica cómo escribir sus propias aventuras. Habida cuenta 
de que hay muchas clases de juegos de aventuras y muchas microcomputa- 
doras diferentes, no puede abarcar todos los temas, pero describe formas 
de diseñar y de programar todas las características esenciales (y algunas no 
fundamentales) en una forma tal que todo usuario de microcomputadora 
sea capaz de utilizar su propia máquina particular. En aquellos casos en 
que sean posibles métodos diferentes, se recomiendan rutinas distintas, 
por lo que una gran gama de juegos es posible dentro del amplio epígrafe 
de “aventura”. La mayor parte de las rutinas se escriben en una de las 
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versiones de BASIC más populares, la del Sinclair Spectrum, pero en 
aquellos casos en los que hay diferencias importantes entre ésta y otras 
versiones del lenguaje, se dan alternativas que pueden utilizarse, sobre 
todo para Microsoft y BBC BASIC. Pueden obtenerse, por separado, una 
casete de todas las rutinas más importantes del Spectrum incluidas en este 
libro. 

El método utilizado es el que se conoce como programación modular o 
estructurada. Ello significa que un programa se considera como una 
estructura constituida por una serie de módulos. Cada módulo es 
autónomo, generalmente como una subrutina (o, en lenguajes como BBC 
BASIC, un procedimiento), por lo que los módulos diferentes se pueden 
definir de distintas formas para proporcionar programas diferentes. De 
esta manera, muchos juegos diferentes se pueden escribir con solamente 
cambios muy pequeños (los mismos módulos se pueden utilizar una y otra 
vez con modificaciones poco importantes). La programación modular 
tiene otras varias ventajas. Estimula los hábitos de programación que 
facilitan la comprobación de los errores y la depuración de los mismos, 
facilita mucho la transición a lenguajes estructurados tales como Pascal 
para quienes deseen aprender un nuevo lenguaje y hace la actividad de 
diseño de programas más fácil y más elegante. Su único inconveniente real 
es que exige alguna autodisciplina por parte del programador y los 
programas correspondientes pueden utilizar más memoria o llevar más 
tiempo que sus equivalentes no estructurados; sin embargo, estas pérdidas 
posibles están compensadas suficientemente por las ventajas conseguidas. 
Si solamente desea escribir un solo juego que ahorre la mayor cantidad de 
memoria posible y se ejecute lo más rápido posible, tiene poco que ganar 
con la programación estructurada. Pero si lo que tiene previsto es escribir 
varios juegos, o elaborar una biblioteca de rutinas para dichos juegos, el 
trabajo inicial será ampliamente recompensado más adelante. 

¿Pero qué es un juego de aventuras? La única respuesta sencilla a esta 
interrogante es que es muchas cosas a la vez, porque hay gran cantidad de 
variantes. Algunos son de fantasía, otros son de ciencia ficción, otros son 
de carácter histórico y algunos están basados en novelas; los hay que 
utilizan gráficos y algunos de ellos son tridimensionales; algunos son de 
tiempo real (como aquellos en los que se ha de reaccionar de forma 
inmediata al juego y no se puede dejar que se ejecute mientras se toma una 
taza de café porque cuando vuelva ya habrá perdido el juego); algunos 
hacen uso de animación, otros implican laberintos, otros traen consigo la 
resolución de problemas, otros ofrecen recompensas en dinero real y 
finalmente, algunos exigen enormes bases de datos mientras que otros 
pueden ser incluidos en una capacidad de memoria no superior a 8K. Por 
lo anteriormente expuesto, no resulta fácil dar una definición general de 
un juego de aventuras. Sin embargo, hay algunos elementos fundamenta- 
les a todos los juegos de este tipo y los examinaremos en primer lugar. 
Después de un estudio general, emplearemos estos elementos como una 


primera forma de concebir y luego, de programar varios juegos de esta 
naturaleza. 

Hablando en términos generales, un juego de aventuras es una 
simulación de un mundo particular. El jugar a este tipo de juegos significa 
comportarse como si se estuviera viviendo en ese mundo y las secuencias 
de acciones que ha de tomar al ejecutar el juego se podría leer como una 
narración que se hubiera escrito. Su juego de aventuras medio tiene, pues, 
tres elementos básicos: simulación, comportamiento del jugador y narra- 
ción. En el ejemplo con que se inició este capitulo, la simulación es un 
mundo de fantasía como el del Oriente Medio de Tolkien; el comporta- 
miento del jugador incluye la recogida de la caja y el acto de sonreír 
dulcemente y la parte de narración es la forma en que persuadí a un 
gnomo para partir con sus esmeraldas y seguir viviendo para narrar el 
cuento. 

El desarrollo de los juegos de aventuras, aunque haya sucedido tan 
rápidamente, tiene bastante complejidad. No se necesita saber nada acerca 
de dónde proceden para ser capaz de escribirlos, pero vale la pena saber 
que los tres elementos principales proceden de diferentes fuentes que se 
han combinado en muchas formas distintas. Casi con toda certeza, se 
puede aprender algo acerca de escribir juegos de aventuras sabiendo más 
acerca de esas fuentes, pero también es cierto que será capaz de aportar 
algo original a los juegos de su propia cosecha. Una de las razones 
principales para la flexibilidad y variedad de los juegos de aventuras es la 
gama de antecedentes de las personas que los han desarrollado. 

Las fuentes principales de los juegos de aventuras están interrelaciona- 
das de forma inexplicable, pero se pueden identificar cuatro más impor- 
tantes. En primer lugar, el florecimiento de la novela de fantasía popular, 
debido a autores tales como Robert E. Howard (el creador de Conan) y J. 
R. R. Tolkien, ha traido consigo que cada vez más personas se sientan 
interesadas por las narraciones fantásticas. En segundo lugar, en los 
últimos años de la década de los “sesenta”, los juegos bélicos llegaron a 
tener una gran aceptación y un tipo de juego bélico en particular, la 
campaña de fantasía, parece ser que ha interesado a varios jugadores 
diferentes en lugares distintos. El más importante de estos juegos fue el 
jugado por Gary Gygax, que gradualmente llegó a ser el juego fantástico 
más popular, el de las mazmorras y el de los dragones. El éxito de este 
juego ha conducido a decenas de otros juegos de esta naturaleza, algunos 
ubicados en el Salvaje Oeste, algunos en el holocausto de la Tierra, 
algunos entre piratas del siglo XVIII, algunos en el espacio exterior e 
incluso uno denominado de conejos y madrigueras que se basa en la obra 
titulada Watership Down. Todos estos juegos pueden ser fuentes de 
inspiración para microjuegos como se constatará en el Capítulo 2. 

En tercer lugar, a casi el mismo tiempo que se produjo la popularidad 
de las noveles fantásticas y de los juegos bélicos tuvo lugar una importante 
investigación en la lingúística de las computadoras (el estudio del lenguaje 
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utilizando computadoras) y la inteligencia artificial (aprendiendo acerca 
de la inteligencia humana intentando hacer máquinas inteligentes). 
principalmente en el Instituto de Tecnología (Institute of Technology) de 
Massachusetts. En este caso, se utilizaron programas que analizaron y 
actuaron sobre el lenguaje natural ordinario; programas que investigaron 
la naturaleza de la resolución de juegos de enigmas y de problemas y 
programas que se utilizaron para manipular mundos ficticios. 

Finalmente, en los campos de la docencia y de los negocios se han 
utilizado, durante muchos años, juegos y simulaciones para servir de 
enseñanza acerca del mundo real. No es posible para los estudiantes 
aprender acerca de las actividades bancarias o de la Conquista Normanda, 
de primera mano, pero pueden conseguir su aprendizaje tomando parte en 
una simulación que les hace actuar como si hubieran estado en esa 
situación. Las microcomputadoras son una herramienta excelente para 
dichas simulaciones y juegos educativos simples, tales como Kingdom (en 
el que el jugador aprende economía elemental) se han hecho populares 
fuera del aula. 

Examinaremos todos ellos en los capítulos sucesivos. Las novelas 
fantásticas pueden darnos ideas para narraciones; los juegos de sobremesa 
y de tableros pueden sugerirnos mecanismos y estructuras de juegos; la 
lingúística y la inteligencia artificial pueden ayudar en el procesamiento de 
textos y en la elaboración de juegos más interesantes y más realistas y 
finalmente, simulaciones “serias” pueden darnos algunos conocimientos 
sobre cómo y por qué juegan las personas interesadas. Pero la finalidad 
principal de este libro es ayudarle a realizar la programación de juegos. 
Examinaremos los diferentes componentes del juego de aventuras, tales 
como mapas, monstruos y elementos mágicos y cómo estos ingredientes se 
pueden programar. Examinaremos las ventajas y las desventajas de 
diferentes técnicas, tales como las diversas formas de almacenar datos. 
Estudiaremos algunas de las palabras de la jerga más ordinarias, tales 
como “acceso aleatorio” y “menús” para explicarlas en un contexto 
sencillo. Examinaremos la forma de conseguir los juegos y de cómo 
esos diseños se pueden traducir en el lenguaje BASIC. Asimismo, estudia- 
remos las formas en que la microcomputadora se puede utilizar para 
prestar su asistencia a los juegos de aventuras que no se ejecuten en una 
microcomputadora. Haremos todo ello escribiendo nuestros propios 
juegos de aventuras a medida que avancemos en nuestra lectura. 

El libro está organizado de la siguiente forma. Comenzamos exami- 
nando los diferentes constituyentes del juego y las diferentes clases de 
juegos de aventuras. A continuación, llegamos a la parte principal del 
libro que está constituida por siete capítulos dedicados a las técnicas de 
diseño y de programación para su empleo en tales juegos, comenzando 
con el diseño global y avanzando a través de todos los componentes 
principales. Cada sección proporciona una o más rutinas que se pueden 
incorporar a sus propios programas hasta que gradualmente vaya elabo- 
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rando, por sí mismo, dos juegos íntegros: El Trono de Camelot y las 
Minas de Merlín. Entre estos dos juegos se ilustra la mayor parte de los 
principios esenciales tratados en cada capítulo, conteniendo, asimismo, 
muchas rutinas que se podrán utilizar en otras aventuras. 


COMPONENTES DEL 
Z JUEGO DE AVENTURAS 


2.1 Elección 


El jugar un determinado juego, utilizando estrategia y táctica, es una 
cuestión de hacer una serie de elecciones. Cada elección depende de otras 
anteriores, por lo que si el jugador hace la elección errónea perderá el 
juego. La escritura de un juego es un proceso de establecer un conjunto de 
elecciones posibles para que las ejecute libremente el jugador. Por 
consiguiente, la orden BASIC fundamental para un juego es IF... THEN... 
(en inglés IF significa sí y THEN significa entonces, por lo que esta orden 
tiene el significado en español de SI... ENTONCES...). Si el jugador elige 
hacer (a) e: tonces sucederá (b), pero si elige (x) entonces el resultado será 
(y). 

Por consiguiente, si deseamos escribir un juego bien estructurado 
debemos hacer tres cosas: 


1. Ofrecer al jugador algunas elecciones de prueba o de interés. 

2. Organizar dichas elecciones de una forma coherente, de modo que las 
elecciones condicionales encajen de forma idónea. 

3. Realizar las interrelaciones entre las elecciones suficientemente comple- 
jas para que valga la pena resolverlas, pero lo bastante sencillas para 
que se puedan resolver. 


Más adelante examinaremos las implicaciones de programación corres- 
pondientes, pero hemos de indicar como lección preliminar que el juego 
debe ejecutarse de una manera sencilla aunque esa aparente sencillez debe 
depender de los recursos ocultos complejos en la programación. 

Los juegos de aventuras pueden depender de muchas clases de elección. 
Inicialmente, el jugador puede ser capaz de elegir el tipo de protagonista 
que el mismo va a desempeñar antes de que se inicie el juego o la 
configuración de dicho juego (tal como su nivel de dificultad o el número 
de sucesos que puedan producirse), diversas acciones en diferentes situa- 
ciones (v.g., huida de, diálogo con, o lucha contra un dragón encontrado), 
cuándo utilizar recursos limitados o incluso cuándo finalizar el juego 
(como con la característica funciona SAVE incorporada en muchos juegos 
de enigmas). 

De momento, siendo algo pedantes podríamos llamar estrategia de un 
jugador a una serie de elecciones destinadas a optimizar las recompensas 
en un juego. De este modo, las elecciones que hacen interesante un juego 
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dependen de la clase de premios que ofrece dicho juego. Al nivel más 
abstracto, un juego ofrece puntuaciones (como es el caso del juego de las 
Minas de Merlín en el Capítulo 6). Cuanto mejor es el jugador, tanto más 
alta será su puntuación; esto es, cuanto mejor sea su estrategia, o la serie 
de elecciones que haga, tantos más puntos conseguirá. 

Podríamos tener un juego muy sencillo en el que el jugador tenga que 
adivinar un número entre 1 y 9 elegido por la computadora. El jugador 
selecciona un número, hace un intento de acierto y la computadora le 
indica al jugador si su número elegido es más alto o más bajo que el 
número que ha de adivinar. El jugador comienza con una puntuación de 
100. Cada vez que él hace una conjetura para intentar el acierto, pierde 10 
puntos, por lo que cuanto mejor sean sus conjeturas tanto más alta será su 
puntuación final. Inicialmente, tiene tres elecciones principales o tres 
posibles estrategias. Puede decir números de forma aleatoria; puede 
empezar en un extremo de la escala e ir subiendo o bajando hasta que 
acierte el número correcto o bien, puede utilizar la rutina siguiente: 


1. CONJETURA 5 

2. SI EL NUMERO ES MAS BAJO QUE 5, ELIGE 3; DE NO SER ASI 
ELIGE 7, 

3. SI SE ELIGIO 7, Y EL NUMERO ES MAS BAJO, ENTONCES LA 
RESPUESTA ES 6. 

4. SI SE ELIGIO 7 Y LA RESPUESTA ES MAS ALTA, ELIGE 9. 

5. SI SE ELIGE 9 Y EL NUMERO ES MAS BAJO, ENTONCES LA 
RESPUESTA ES 8. 

6. SI SE ELIGIO 3 Y EL NUMERO ES MAS ALTO, ENTONCES LA 
RESPUESTA ES 4. 

7. SI SE ELIGIO 3 Y LA RESPUESTA ES MAS BAJA, ENTONCES 
ELIGE 1. 

8. SI SE ELIGIO 1 Y LA RESPUESTA ES MAS ALTA, ENTONCES 
LA RESPUESTA ES 2. 


Si el jugador elige la estrategia aleatoria, puede hacer hasta ocho 
conjeturas para elegir la respuesta correcta y debe tener un promedio de 
cinco. Si elige la segunda estrategia, lo mismo es probablemente cierto. Sin 
embargo, para la tercera estrategia, el número de conjeturas, o suposicio- 
nes, nunca es superior a cuatro por lo que el jugador siempre obtendrá 
una puntuación mínima de 60 puntos y probablemente tendrá un prome- 
dio de 80. Evidentemente, la mejor estrategia es la tercera porque, en cada 
etapa en juego, se realiza la mejor elección de todas las disponibles; esto 
es, la elección que reduce el número de conjeturas futuras posibles al valor 
más pequeño. 

Con el fin de conseguir una idea de cuán equilibrado está su juego, 
mientras está diseñándolo, utilice un sistema de puntuación contra todas 
las opciones como una medida aproximada de la dificultad, recompensa y 
balance incorporador al juego. No necesita incorporar ese sistema al 
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propio juego real, pero puede ser una gran ayuda en su diseño para 
permitirle saber cuán fácil y complejo es realmente su juego. Por ejemplo, 
si considera que cada problema en su juego es tan fácil de resolver que 
solamente vale la recompensa de un solo punto quedaría sorprendido 
durante la prueba de dicho juego si se encontrara con que tardaría una 
media hora en conseguir una puntuación de dos puntos. Ello significaría 
que había un defecto de diseño para que suceda algo semejante. Acaso los 
problemas sean más difíciles de lo que usted pensaba, quizá las recompen- 
sas del juego no sean lo suficientemente grandes, acaso la estructura total 
es defectuosa o quizá se necesitan más pistas o instrucciones. 

Sin embargo, los puntos no son la única clase de recompensa. Si 
consideramos a nuestro aventurero compulsivo (de forma abreviada, Cad) 
como siendo una especie de máquina jugadora que ejecuta un programa 
denominado “disfrutaré si me mata”, podemos considerar la RECOM- 
PENSA (REWARD) como una de las variables en ese programa que 
determina si se ejecuta, o no, de forma satisfactoria. Si la recompensa es 
inferior a 1, finalizará el programa. Pero se pueden dar valores a esa 
variable, mediante un conjunto de funciones, de las cuales solamente una 
es la función de “aumentar puntos”. 

Normalmente, hay dos clases de funciones de recompensa a las que 
responderá el ““aventurero” Cad; a saber, recompensas locales y recom- 
pensas globales. Una recompensa local es aquella que incrementa tempo- 
ralmente el valor de la recompensa como consecuencia de una acción que 
acaba de realizar, pero que no tiene ningún efecto permanente sobre el 
resto del juego. Por ejemplo, nuestro héroe puede matar al Gran 
Monstruo del Pantano Verde. Se sentirá recompensado la primera vez que 
lo consiga, pero si no obtiene ningún punto, ni encuentra ningún tesoro ni 
ninguna pista, ni supone incrementar su destreza, etc., lo olvidará. 
Algunos juegos están constituidos por una serie de dichas recompensas 
locales y no existe ninguna recompensa acumulativa, solamente una serie 
de incrementos temporales en su valor. En el caso de dichos juegos, debe 
mantenerse los éxitos bastante próximos, de modo que no haya tiempo 
para que la recompensa (REWARD) sea inferior a 1; además, cada 
victoria debe ser diferente o nueva o no se incrementará la recompensa. 

Las funciones globales que incrementan la recompensa son la base de 
las aventuras atractivas. Al jugador se le debe dar suficientes éxitos locales 
para que vaya avanzando de una etapa a otra, pero solamente deseará 
completar el juego, para conservar su retorno, si algunos éxitos aumentan 
sus posibilidades de conseguir una victoria total. En nuestro anterior juego 
simplista de adiviniación de números, el jugador continuará jugando 
mientras él considere que está más próximo a una solución, pero si 
cualquier conjetura no influyera sobre las posibilidades de un acierto 
futuro, rápidamente perdería su interés. Asimismo, ha de tenerse en 
cuenta que puede llegar a preguntarse qué interés tiene el juego sin nada 
que haga aumentar su posibilidad total de vencer. 


Por consiguiente, el juego de aventuras típico tiene una serie de 
obstáculos a superar con el fin de conseguir la solución final. Cada 
obstáculo salvado actuará como una recompensa local e incrementará 
temporalmente el valor de la recompensa final (REWARD). Transcurrido 
un cierto tiempo, dicho incremento temporal se perderá, pero habrá 
todavía un incremento total porque el jugador sabrá que ahora está 
mucho más cerca de la solución. Estos obstáculos pueden ser problemas a 
resolver, objetos a encontrar, laberintos a superar, monstruos a derrotar, 
preguntas a responder, etc. Un problema simple tal como “¿Cómo abriré 
la puerta?” puede proporcionar suficiente recompensa para mantener a un 
jugador durante varias horas cuando sepa que la solución está al otro lado 
de esa puerta. 

Sin embargo las recompensas globales se dan con cuatro epígrafes: 
soluciones, puntuaciones, tesoro y capacidades incrementadas. Las solucio- 
nes permiten que se resuelvan enigmas, problemas, adivinanzas y elemen- 
tos similares. Estos elementos proporcionan la base de un tipo principal de 
juego de aventuras, que llamaré el juego de los enigmas. Esencialmente, 
un juego de enigmas es un conjunto de enigmas interrelacionados que 
constituyen un enigma total. Para poder encontrar la solución total, debe 
resolverse cada uno de los problemas por separado y en el orden correcto. 
Por consiguiente, en cualquier fase del juego, el jugador tendrá dos 
objetivos: (1) resolver el problema local particular que se le plantea en ese 
momento y (2) resolver el problema total. Evidentemente, cualquier cosa 
que le ayude en el primer objetivo contará como una recompensa local 
para su criterio y aumentará su satisfacción de forma temporal, mientras 
que cualquier cosa que contribuya al segundo objetivo le proporcionará 
un incremento permanente en el valor de la recompensa final (RE- 
WARD). La victoria en esta clase de juego es algo así como resolver el 
Cubo de Rubik. Se experimenta un cierto placer en conseguir colocar en 
su lugar cada cuadro coloreado individual, pero ello no es nada en 
comparación con la sensación producida cuando se llega a la solución 
final. 

Ya hemos tratado el tema de las puntuaciones. El tesoro y las aptitudes 
pertenecen a la segunda clase de juego de aventuras, el juego de combates. 
En este caso, la tarea total puede ser muy similar al del juego de los 
enigmas (v.g., el hallazgo de un amuleto oculto), pero el método de 
conseguirlo es muy diferente. En lugar de tener que resolver una serie de 
problemas, el jugador actúa como un aventurero en una novela de 
“espadas y hechizos”, enfrentándose a bestias, abatiéndolas y luego 
apoderándose de cualquier tesoro que puedan tener. En la acumulación 
del tesoro es algo así como el aumento de la puntuación y constituye una 
clase abstracta de recompensa. Sin embargo, se hacen global si el tesoro se 
puede utilizar luego para otros fines, tal como la adquisición de aditamen- 
tos que le ayude en otras búsquedas o combates, sobornando a monstruos 
o aumentando mágicamente sus capacidades. En algunos juegos, la tarea 
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no se puede conseguir hasta que el personaje del jugador haya desarrolla- 
do un cierto nivel de capacidad (que suele denominarse el nivel de 
experiencia, después del concepto utilizado en mazmorras y dragones). 
Puede conseguirlo mediante un éxito en un combate, lo mismo que en la 
vida real las gentes obtienen el máximo partido de las cosas con una 
práctica satisfactoria o bien, puede conseguirlo recibiendo incrementos 
mágicos a través de tesoros particulares encontrados. 

Las interrelaciones entre tesoros, capacidades, puntuaciones y algunas 
otras variables se harán más claras en el Capítulo 6, cuando diseñemos un 
juego de combates. En el Capítulo 5 que se relaciona con el diseño de un 
juego de enigmas será cuando veremos cómo se pueden adaptar las 
recompensas locales y globales. Sin embargo, el problema que encontrare- 
mos a través de todo el libro será que los dos tipos de juego son difíciles de 
combinar. Casi todos los juegos de aventuras son juegos de enigmas o bien 
juegos de combates y resulta difícil cualquier tentativa de combinar estas 
dos clases. Ello es, en parte una consecuencia de las limitaciones de las 
memorias en las microcomputadoras, pero sobre todo se debe a que los 
programadores no están dispuestos a implicarse en la complejidad de 
dicha mezcla. Tenemos la esperanza de que cuando haya leído este libro 
tendrá los suficientes conocimientos sobre ambas clases de juegos para ser 
capaz de desarrollar el primero de una nueva clase de juego de aventuras, 
en el que se mezcle los de enigmas y los de luchas. 

En el resto de este capítulo, examinaremos algunos de los elementos 
fundamentales de un juego de aventuras de forma bosquejada, antes de 
pasar a la codificación y diseño detallados de los programas en capítulos 
sucesivos. Sin embargo, se deducirá de lo anteriormente expuesto que los 
elementos básicos en el juego son una persona, o protagonista de alguna 
clase, que realiza el juego, una línea de narración constituida por una serie 
de elecciones y varios riesgos que se plantean. 


2.2 Narraciones 


En primer lugar, examinaremos la estructura de la narración de los juegos. 
La narración es lo que da sentido al juego, haciéndole un algo coherente 
más bien que una serie aleatoria de sucesos. La planificación de una 
narración original, o lo que los diseñadores de juegos suelen denominar 
un escenario, puede ser la diferencia entre un juego que dé la sensación de 
ser un programa de computadora y un juego que aparente ser una 
exploración real. 

Una narración es una serie de sucesos que conducen a una consecuen- 
cia principal. Los sucesos le acontecen a un protagonista principal, o a un 
grupo de protagonistas, y la consecuencia suele ser la muerte del 
protagonista o la consecución de un objetivo particular. En los términos 
del juego, el protagonista es la persona del jugador (tratada en la siguiente 
sección) y la consecuencia es la terminación satisfactoria del juego 
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(equivalente a conseguir el objetivo o a hacer máximo el valor de la 
recompensa) o una terminación no satisfactoria (equivalente a la muerte). 
Un suceso en una narración suele responder a la fórmula siguiente: 


PROTAGONISTA PRINCIPAL + LUGAR + TIEMPO + OTROS 
PROTAGONISTAS + OBJETOS + ACCIONES POSIBLES + CONSE- 
CUENCIAS POSIBLES. 


De este modo, un suceso en un juego de aventuras debe tener, en 
condiciones ideales, todos los componentes de la anterior fórmula y 
nuestro programa es un sistema para obtener conjuntos de dichos 
componentes, de tal modo que cada uno de dichos conjuntos constituya 
un suceso coherente. No todos los sucesos necesitarán la totalidad de los 
componentes citados, pero siempre serán necesarios algunos de ellos. Una 
serie de dichos sucesos forman la narración y corresponde al progreso del 
personaje del jugador a través de las localizaciones representadas en el 
juego de aventuras. Los enlaces entre dichas localizaciones pueden ser 
totalmente aleatorias o totalmente estructuradas o una combinación de 
ambas. Lo mismo sucede con los acontecimientos. La ventaja de la 
determinación aleatoria es que resulta fácil de programar y puede 
proporcionar una gran variedad. Su desventaja principal es que un juego 
aleatorio se hace enojoso con rapidez porque está constituido por una 
serie de hechos imprevisibles sin ninguna relación lógica; esto es, una serie 
de recompensas meramente locales. Una decisión tomada en una localiza- 
ción no tendrá ningún efecto sobre las sanciones subsiguientes a no ser que 
el personaje del jugador se modifique en alguna forma en dicha localiza- 
ción (se haga más débil o, quizá, encuentre una espada lasérica). La 
adición de esta clase de modificación a un juego básicamente aleatorio es 
bastante fácil de conseguir como pondremos de manifiesto en el Capítu- 
lo 6. Proporciona una forma sencilla de añadir alguna estructura a nuestro 
juego. Sin embargo, si no se produce ninguna de dichas alteraciones en 
cualquier localización, los sucesos no están relacionados y, en realidad, 
tenemos una serie de pequeños juegos más bien que un juego de gran 
magnitud. Este procedimiento, que utiliza una serie aleatoria de sucesos 
que se relacionan solamente por su efecto sobre el personaje central, suele 
ser una serie de recintos en cada uno de los cuales hay una posibilidad 
porcentual de que existan OTROS PROTAGONISTAS (normalmente 
monstruos) u OBJETOS (tesoros, armas, alimentos) o ACCIONES (caer 
en un pozo, ponerse enfermo, leer una inscripción). Por ejemplo, cada 
recinto en una mazmorra podría contener un suceso construido de la 
manera siguiente: 


l. GENERAR NUMERO ALEATORIO A EN EL MARGEN 1-10 
2. GENERAR NUMERO ALEATORIO B EN EL MARGEN 1-10 
3. GENERAR NUMERO ALEATORIO C EN EL MARGEN 1-10 


4. SIA ES MAS GRANDE QUE 4, ENTONCES GENERAR NUMERO 
ALEATORIO D EN EL MARGEN 1-4 

5. ESTE RECINTO CONTIENE MONSTRUO(D) 

6. SIB ES MAS GRANDE QUE 4 ENTONCES GENERAR NUMERO 
ALEATORIO E EN EL MARGEN 1-4 

7. ESTE RECINTO CONTIENE OBJETO(E) 

8. SI C ES MAYOR QUE 6 ENTONCES GENERAR UN NUMERO 
ALEATORIO F EN EL MARGEN 1-4 

9. ESTE RECINTO CONTIENE ACCION(F) 


Los números aleatorios A, B y C deciden si debe existir un monstruo, 
objeto y acción en un recinto particular; los números aleatorios D, E y F 
seleccionan el monstruo, objeto y acción correspondiente si los hubiere. 
De este modo, se constituiría un programa con el empleo de matrices o 
subrutinas a partir de las cuales podrían ser objeto de llamada elementos 
aleatorios. Cada elemento aleatoriamente elegido sería un conjunto de 
variables que modificaría potencialmente, en alguna forma, al protagonis- 
ta. En otros capítulos se dan muestras de monstruos, objetos y acciones. 

El procedimiento opuesto, que es el de una serie de acontecimientos 
totalmente estructurados, es característico del juego de enigmas. En este 
caso, la tarea no es sobrevivir a tantos acontecimientos aleatoriamente 
generados como sea posible, sino descubrir el enigma o la narración y 
pasar a través de cada uno de los sucesos planificados en el orden correcto. 
Por ejemplo, el aventurero puede encontrarse con que no puede avanzar 
en el fuego hasta que no haya descubierto cómo abrir una trampilla 
oxidada. Para descubrirlo, debe sobornar a un duende, lo que significa que 
ha de encontrar algún dinero. Para conseguir el dinero, debe pasar 
primero al fantasma sin cabeza, y así sucesivamente. La ventaja de este 
tipo de juego es que es una forma real de las capacidades del jugador, de 
su inteligencia, de su capacidad lógica y de su imaginación, y no 
simplemente una prueba de reacciones o de respuestas a una serie 
aleatoria de accidentes. El juego de aventuras de enigmas se ha comparado 
con la realización de un crucigrama, puesto que exige la misma clase de 
aptitudes, incluyendo el dominio del lenguaje, y todas las partes se deben 
resolver para completar el conjunto. 

La desventaja principal de una serie de sucesos totalmente estructurada 
es que el juego es el mismo cada vez que se ejecuta. No hay ninguna 
novedad, ni nada imprevisible, como en una mazmorra aleatoria; las 
etapas iniciales se pueden hacer aburridas con el juego repetitivo y una vez 
resuelto no se volverá a jugar otra vez. Asimismo, se trata de una prueba 
mucho más severa de la imaginación y de la capacidad del programador, 
puesto que un juego completamente estructurado exige un programa 
también muy estructurado. 

Al diseñar nuestro juego, debemos tener presente que el jugador debe 
sentirse, al menos en parte, como si estuviera avanzando a través de una 
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narración. No importa si algunos de los elementos son aleatorios o 
completamente predeterminados, pero deben parecer coherentes desde el 
punto de vista de quien lo juega. Es importante, por consiguiente, que su 
personaje tenga sentido. 


2.3 El protagonista del jugador 


El protagonista es la persona del jugador y es la unidad que representa al 
aventurero Cad en el juego. Si se destruye el personaje, el juego ha 
concluido. Utilizaremos la denominación de protagonista aun cuando se 
trate de un monstruo o de una nave o vehículo espacial que el jugador esté 
pretendiendo ser, porque esencialmente se trata de las capacidades y del 
comportamiento de ese elemento del juego lo que hace entretenido los 
juegos de aventuras de combates. Sin embargo, en el juego de enigmas, el 
jugador rara vez tiene un protagonista definido o variable, lo que 
constituye uno de sus inconvenientes. Sería preferible si los juegos de 
aventuras de enigmas se concibieran de modo que configuraciones de 
personajes diferentes fueran capaces de abordar la solución de forma 
distinta, pero ello daría lugar a grandes problemas de programación, 
como se verá más adelante. Por consiguiente en el juego de aventuras de 
enigmas, es la propia personalidad del jugador la que es objeto de prueba 
y no la personalidad atribuida de su personaje. 

En términos de programación o del juego, el protagonista es un 
conjunto de números que se pueden modificar a medida que avanza el 
juego. Por ejemplo, si el personaje es un caballero medieval, se podría 
considerar como: 


Velocidad 4 
Defensa 5 
Ataque 4 


En donde el máximo es 6. Si pierde su caballo, su armadura o su espada, 
estos números podrían disminuir. Si bebió una poción mágica, encontró 
una maza o doblegó a un dragón, dichos números se podrían incrementar. 
Cada vez que el jugador ha de tomar una decisión en el juego, su 
posibilidad de éxito dependerá del valor actual de uno o más de estos 
números. Por consiguiente, si tuviera que decidir de participar en una 
carrera, el éxito dependería de la velocidad; si quisiera luchar contra un 
gigante, el éxito podría depender de los valores correspondientes del 
ataque y de la defensa. 

Dicho de otro modo, un protagonista es un conjunto de variables. 
Dichas variables pueden estar relacionadas o no estarlo, pero para 
aumentar el interés de un juego suele ser una buena idea enlazar dichas 
variables de alguna manera. Ello da al personaje de la aventura más que 
pensar. Por ejemplo, el montar un dragón podría aumentar la velocidad 
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pero podría disminuir la capacidad de ataque (porque la espada del 
guerrero no puede alcanzar al enemigo desde el lomo del dragón). Sin 
embargo, si consigue una lanza, ello incrementaría el valor de su 
capacidad de ataque a lomos del dragón, pero podría reducir su capacidad 
de defensa porque resultaría más difícil utilizar un escudo con una lanza 
que con una espada. Ahora, según lo anteriormente expuesto, el personaje 
tendría que pensar si le conviene montar en el dragón o no le resulta 
conveniente. 

Normalmente, un conjunto de variables es preferible que se conserve 
como una matriz, por lo que comenzaremos por elaborar la matriz para 
nuestro primer personaje, que también se utilizará en un juego posterior. 
Le llamaremos Sir Jon (su madre quería que fuese un doctor). Mantendre- 
mos sus variables en una matriz A(4) y le daremos cuatro variables para 
empezar: fortaleza, destreza, constitución y conocimiento. Por consiguien- 
te, necesitamos dimensionar una matriz con sólo cuatro variables. Ello 
podría ser un desperdicio de memoria, pero cuando desarrollemos más 
adelante este personaje necesitaremos la flexibilidad de una matriz. Al 
haber dimensionado la matriz, podremos leer (READ) en ella con los 
datos (DATA) iniciales; esto es, los valores que se asignaron inicialmente 
a las variables, o las capacidades que se atribuyen inicialmente al 
personaje. Supongamos que la fortaleza y el conocimiento tiene un valor 2 
y que la destreza y la constitución tiene un valor 1. Por consiguiente, 
nuestra rutina para establecer el personaje sería: 


8000 REM Establecimiento del personaje Sir Jon 
8010 DIM A(4) 

8020 FOR I=1 TO 4 

8030 READ A(D) 

9000 REM Datos de Sir Jon 

9010 DATA 2,2,1,1 


Naturalmente, estos valores no serán arbitrarios. Debemos tener 
alguna idea sobre cuál será probablemente el margen de dichos valores. 
Por consiguiente, la concepción de un personaje está ligada, en gran 
medida, con lo que el personaje vaya a hacer en el juego y con lo que el 
juego podría hacerle a él. Por ejemplo, si deseamos que exista la 
posibilidad de que un personaje débil luche contra monstruos fuertes, 
podríamos permitir un margen de 0 a 9 para la fortaleza, pero no permitir 
que cualquier personaje tenga un valor de la fortaleza superior a 6. 

Sin embargo, si la fortaleza, A(1), es una variable a utilizar en rutinas 
que no sean las de combate (tal como una rutina para elevar objetos 
pesados), debemos asegurarnos de que el margen es también adecuado 
para estas rutinas y que el valor inicial se establece para un nivel que tenga 
significado. Normalmente, desearemos que las variables del protagonista 
se ajusten al nivel más bajo en el margen (si el juego está primariamente 
concebido con la idea de mejorar las capacidades) o al valor más alto (si el 
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juego está concebido para evitar la debilidad). Asimismo, podríamos 
desear establecer algunas variables en su punto medio, con el significado 
“normal” o “media”, si son de tipo de variables que se podrían mejorar o 
empeorar. Supongamos que Sir Jon tiene un valor medio en lo que 
respecta a la fortaleza y al conocimiento, que comienza su andadura con 
poco entrenamiento (y, por consiguiente, con poca destreza) y que, al estar 
bastante desnutrido, su constitución es débil. Si el margen para todas las 
variables es de O a 9, los valores correspondientes a Sir Jon podrían ser: 


A(1)=4 
A(2)=4 
A(3)=0 
A(4)=1 


Estaremos a la espera de que mejore su destreza y su constitución 
mediante disciplina y trabajo duro y supondremos también que podría 
hacerse más fuerte o más débil, adquirir más conocimientos o perderlos. 

Añadamos también una variable que comience en un máximo de 9 y 
que solamente se pueda reducir durante el juego. Supongamos que Sir Jon 
tiene 9 deseos mágicos que se le han concedido en su nacimiento. 
Añadiremos LET A(5=9 a la matriz, recordando que tenemos que 
cambiar también las sentencias DIM y FOR...NEXT. Sir Jon será capaz 
de utilizar estos deseos en puntos cruciales a través del juego. 

El objetivo de Sir Jon en esta aventura será llegar a ser un guerrero de 
la Tabla Redonda. No solamente podemos utilizar las variables relaciona- 
das con el personaje para calcular cada situación que se produzca, sino 
que también podemos emplearlas para decidir cuando a Sir Jon le merece 
la pena llegar a ser dicho caballero. Haremos la prueba fácil de iniciar y 
luego, la iremos complicando a medida que se desarrolle el juego. 
Supondremos que si Sir Jon tiene un valor de conocimiento de 8 o más y 
su fortaleza es de 8 o más, entonces, puede llegar a ser un miembro de la 
orden sagrada de la Tabla Redonda. Ello lo podremos expresar como una 
sola línea de lenguaje BASIC: 


IF A(1)>=8 AND A(2)>=8 THEN LET TABLAREDONDA=1 


La variable TABLAREDONDA se utilizará como un indicador; eso es, 
una variable que indica si Sir Jon es un Caballero de la Tabla Redonda o 
no lo es. Si el indicador se pone a 1, entonces lo será; si se pone a 0, no lo 
será. : 

El objetivo principal de Cad será, pues, incrementar la fortaleza y el 
conocimiento, mientras que sus objetivos secundarios serán incrementar la 
destreza y la constitución en la medida que le sirvan para conseguir su 
objetivo principal. Al mismo tiempo, tendrá el deseo de conservar sus 
nueve deseos para utilizarlos en los momentos más vitales. Por consiguien- 
te, las recompensas del programa serán incrementos en estas variables. 

Sin embargo, también podemos añadir una recompensa de puntuación 


15 


más abstracta para aquellos jugadores a quienes les guste tales cosas. 
Podemos inventar una puntuación total dependiente de lo bien que lo 
haga el personaje. En el caso de Sir Jon, parecer ser importante que un 
caballero se comportara de la forma más honorable posible, por lo que le 
daremos los puntos correspondientes al honor dependiendo de lo bien que 
actúe en situaciones particulares. Si establecemos esta escala de 1 a 100 y 
lo registramos como A(6) (sin olvidar cambiar las sentencias correspon- 
dientes), también podemos incorporar esta puntuación abstracta en la 
prueba para conseguir la encomienda. Supongamos que para que sea 
admitido a la Tabla Redonda un Caballero debe ser muy honorable, con 
un valor total del honor superior a 90. Podemos añadir que este grado de 
honor tendrá más valor si no ha utilizado sus deseos para servirle de 
ayuda (lo ha conseguido por su propia cuenta sin ayuda sobrenatural), de 
modo que para cada deseo pierda en su puntuación 5 unidades de honor. 
Ello significa que los puntos totales de honor serán los que normalmente 
se añadan a A(6) más 5* A(5). Nuestra prueba para la consecución de la 
encomienda (obtención del grado de caballero) se ha convertido en una 
rutina corta: 


7799 REM PRUEBA DE LA ENCOMIENDA 

7800 LET HP = 0:REM BORRAR CUALQUIER VALOR ANTE- 
RIOR 

7810 LET HP = (A(5)*5)+A(6) 

7820 IF A(1) >= 8 AND A(2) >= 8 AND HP>90 THEN LET 
TABLAREDONDA =1 

7830 RETURN 


La línea 7810 tiene más paréntesis que en algunas versiones de BASIC 
podría parecer necesario. Versiones diferentes del lenguaje tienen priorida- 
des diferentes para evaluar las expresiones, por lo que es conveniente 
mantener explícita la expresión. 

En el juego de aventuras de enigmas, el protagonista es menos 
importante que en el juego de combates. Normalmente, el personaje no 
tiene ninguna característica variable. Por el contrario, la persona del 
jugador solamente varía según los objetos o elementos recogidos. En 
efecto, la diferencia es que, mientras en el juego de combates la persona 
tiene un conjunto de atributos constante cuyos valores reales son objeto de 
variación, en el juego de enigmas son los propios atributos los que varían 
pero cada atributo particular tiene un valor constante. 

Por ejemplo, el enigma puede implicar el hallazgo de una manzana 
(para poder sobornar a un perceptor), encontrar un explosivo (para hacer 
un agujero en una puerta) o encontrar una moneda (para sobornar a un 
guarda). Cada uno de estos objetos, (a), (b) y (c), tiene un valor 
constante en términos del programa: (a) tiene el valor de “permite el 
soborno del preceptor”, (b) tiene el valor de “abre la puerta” y (c) tiene el 
valor de “sobornar al guarda”. El personaje puede hacer cualquier 
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combinación de estos a la vez; v.g. (a+b), (a+c), (b+0), etc., lo que 
significa que las tareas que el personaje puede realizar satisfactoriamente 
en un momento particular variarán lo mismo que ocurría en el juego de 
lucha. 

Se podría utilizar una matriz para retener esta información lo mismo 
que en el juego de combate. Cada variable en la matriz se utilizará como 
un indicador para representar un objeto particular. Si el indicador 
correcto se pone a 1, el personaje posee dicho objeto; si se pone a 0, no lo 
tiene. Sin embargo, observará que en el programa de el Trono de Camelot, 
cuando lo elaboremos en el Capítulo 5, que estos indicadores se pueden 
utilizar para otros fines que señalen diversos estados del objeto en 
cuestión. Después de todo, cualquier variable particular en un programa 
utiliza, como mínimo un octeto de memoria, y no simplemente un bit. Un 
bit de información es efectivamente un indicador que sólo se puede poner 
aloa0; esto es, sólo tiene dos estados posibles. Dicho de otro modo, es 
un valor binario y precisamente, bit significa Binary InTeger —Entero 
Binario. 

Sin embargo, un octeto puede tener 256 estados diferentes, que es la 
razón por lo que muchos aspectos del BASIC están limitados a 256. Si 
examinamos el juego de caracteres del Spectrum en el Apéndice A del 
Manual, observaremos que está constituido por 256 códigos. Un octeto 
está constituido por 8 bits que permite la codificación de números hasta 
256 utilizando el sistema binario de conteo. En consecuencia, cualquier 
variable que se puede poner a 1 en un programa de BASIC también se 
puede poner a 255 (el 256." estado será cero, que es también un número). 
Por ello, si utilizamos dichos indicadores en un juego de enigmas, 
podríamos utilizar un sistema como el siguiente: 


0 significa que el objeto está oculto. 

l significa que el objeto se puede ver. 

2 significa que el jugador tiene el juego. 

3 significa que lo ha utilizado en forma correcta. 
4 significa que lo ha puesto en el lugar correcto. 
Y así sucesivamente hasta 255. 


El sistema de indicadores utilizados en el programa del Trono de Camelot 
es similar al anterior y se explica en el Capítulo 5. De este modo, la 
combinación de dicho conjunto de indicadores corresponde a una descrip- 
ción del nivel actual de consecución del protagonista; esto es, la etapa que 
ha alcanzado en la resolución de todos los problemas. Si su juego es 
primariamente un juego de enigmas, para poder diseñar su protagonista 
tendrá que considerar todos los enigmas que han de resolverse y qué 
conjunto de indicadores registrará mejor todas sus etapas posibles. Por 
supuesto, es posible asignar un indicador diferente para cada estado, o 
etapa, posible, pero ello sería un desperdicio de capacidad. En cambio, 
podríamos decidir que hubiera 8 enigmas principales, teniendo cada uno 4 
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etapas. Aunque fuera posible registrar esta información con solamente 2 
indicadores (utilizando métodos que no podemos tratar aquí), resulta más 
fácil tener 8 indicadores con 4 estados posibles (0 a 3 inclusive) en lugar de 
tener 32 indicadores diferentes. 


2.4 Monstruos 


Si el juego ha de tener un elemento de combate, tendrán que existir 
oponentes al protagonista del jugador. Aunque no hubiera ningún 
combate, probablemente habrá seres de alguna clase con los que el 
protagonista tendrá que tener acciones mutuas. Para facilitar las cosas, 
consideraremos que todas las criaturas son monstruos, aunque algunos 
pudieran tener apariencia humana. En mi experiencia, nadie en ninguna 
aventura tiene ningún interés real en ayudar al protagonista y suelen 
participar todos ellos en algún propósito monstruoso por su propia 
cuenta. Los monstruos podrían ser desde ladrones de ganado hasta 
dragones, siendo todos ellos criaturas que no están bajo control del 
jugador. 

Un monstruo será una configuración de números similares a los del 
protagonista del jugador. Aunque puedan contener exactamente el mismo 
margen y tipo de variables que el protagonista, normalmente tendrán un 
margen menor y su tipo será un reflejo de, y estará relacionado con, un 
subconjunto de los atributos del protagonista. Por ejemplo, si el protago- 
nista tiene un valor de ataque, un valor de velocidad y una variable de 
tesoro el monstruo podría tener un valor de defensa, un valor de velocidad 
y una acumulación de tesoro. La rutina de combate dependerá, entonces, 
de las relaciones existentes entre los valores de ataque y de velocidad del 
protagonista y los valores de defensa y de velocidad del monstruo, siendo 
la recompensa por vencer en el combate el tesoro del monstruo o una 
puntuación superior o ambas cosas. 

Como los monstruos son uno de los peligros fundamentales en este 
tipo de juego, proporcionando gran parte de su interés, debemos dedicar 
algún esfuerzo para planificar su diseño, teniendo presente los criterios 
siguientes: 


1. Un monstruo sólo debe tener variables y valores que tengan significado 
con relación al resto del juego. Ello suele significar que esas variables 
han de estar relacionadas con las variables del protagonista del jugador, 
pero, en el caso de un monstruo “inteligente” que pueda actuar en el 
programa con independencia del protagonista, serán necesarias otras 
variables. 

2. No debe ser fácil que el protagonista se encuentre con los monstruos, 
que son extremadamente poderosos, en términos comparativos, a no 
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ser que sea la consecuencia de un error importante (de no ser así, el 
juego llega a ser de “muerte súbita”). 

3. Ningún monstruo debe ser invencible, ni demasiado fácil de derrotar. 
Los monstruos encontrados deben tener un rango de poder que se 
pueda superar por el protagonista o debe tener sus facultades en 
relación con las que tiene el protagonista. 

4. Cada monstruo debe ser diferente, no simplemente en virtud de la 
magnitud de sus variables sino también en función de su configuración 
total; esto es, su nombre, su comportamiento, la clase de problema que 
plantea y, en consecuencia, las elecciones o estrategias necesarias para 
su derrota. 


En términos generales, lo anteriormente expuesto nos da dos clases de 
monstruo: el monstruo que se encuentra de forma aleatoria y el monstruo 
inteligente. El monstruo aleatorio se puede encontrar en cualquier lugar 
adecuado, pero el monstruo inteligente solamente será llamado por el 
programa si se cumplen determinadas condiciones. La función de los 
monstruos aleatorios es relativamente fija, siendo la de responder al 
protagonista normalmente en combate. Los monstruos inteligentes se 
pueden programar con unos atributos y un comportamiento más comple- 
jos, lo que puede llevarles a tener propósitos independientes del protago- 
nista. 

Trabajaremos con el monstruo aleatorio, pues éste es el tipo habitual 
en la mayor parte de las aventuras y es el más fácil de diseñar. Los 
monstruos inteligentes se tratarán en el Capítulo 8. 

Podemos retener los datos, los números que describen cada monstruo 
en una Cualquiera de varias formas, siendo las tres más fáciles en el 
lenguaje BASIC una matriz, una cadena de caracteres y una sentencia 
DATA. 

Examinaremos cada una de estas formas sucesivamente antes de con- 
siderar los datos exactos que iremos a almacenar. Así, supondremos un 
conjunto de datos constituidos por los números 1, 2, 3 y 4. La re- 
tención de dichos datos en una matriz unidimensional significaría una 
matriz diferente para cada monstruo, lo cual es un método posible aunque 
normalmente molesto y desperdiciador de capacidad de memoria. Por 
consiguiente sería preferible utilizar una matriz bidimensional. En la que 
una dimensión retiene la lista de los monstruos y la otra dimensión retiene 
los datos correspondientes a cada uno de esos monstruos. 

Si nuestros monstruos fueran Grendel, Hulk y Roc y sus datos 
correspondientes fueran 1,2,3 y 2,3,4 y 1,3,2 entonces nuestra matriz puede 
considerarse de la forma siguiente: 


Grendel l 2 3 
Hulk 2 3 4 
Roc 1 3 2 
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En este caso, la columna representa el valor y la fila representa a cada 
monstruo particular. Si llamamos a la matriz M, una rutina del Spectrum 
BASIC para crear y rellenar dicha matriz sería: 


10 DIM MG,3) 

20 FOR 1 = 1T0 3 
30 FOR J = 1 TO 3 
40 READ M(LJ) 

50 NEXT J 

60 NEXT I 

70 REM GRENDEL 
80 DATA 1,2,3 

90 REM HULK 

100 DATA 2,3,4 

110 REM ROC 

120 DATA 1,3,2 


Para encontrar el elemento de datos correspondiente en cualquier 
etapa en un juego, el programa necesita saber dos cosas además del 
nombre de la matriz que ha de consultar. Estas cosas son el número del 
monstruo que se examina (la fila de la matriz) y el número del valor 
requerido (la columna de la matriz). Si estuviéramos calculando un 
combate y necesitáramos saber el valor del ataque de Hulk, utilizaríamos 
N(Q,3), que es el tercer elemento en la segunda fila. 

Las matrices son de gran utilidad para este tipo de procedimiento, que 
se suele denominar acceso aleatorio porque cualquier elemento aleatoria- 
mente seleccionado puede ser objeto de acceso tan fácilmente como 
cualquier otro. Sin embargo, las matrices hacen uso de memoria y si 
hubiera un gran número de monstruos en el juego, una matriz para 
contener todos ellos utilizaría una gran cantidad de memoria, lo que sería 
un desperdicio sobre todo si los valores estuvieran solamente comprendi- 
dos en un pequeño margen, tal como de 1 a 4 como anteriormente. La 
matriz M utilizará, como mínimo, 20 octetos en la mayor parte de los 
sistemas, pero nueve números en el margen de 1 a 4 se pueden almacenar 
en solamente cinco octetos y, en realidad, se podrían sobrecargar en 
menos espacio. 

Una forma de ahorrar algo de esta memoria es retener los datos de los 
monstruos en la forma de cadenas de caracteres. Dicha cadena puede 
declararse al principio del programa lo mismo que podríamos dimensio- 
nar la matriz correspondiente. Para nuestro ejemplo actual, la declaración 
de la cadena sería: 


LET M$=*123234132” 


Esta cadena ocuparía solamente nueve octetos, lo que Supone menos de la 
mitad del espacio ocupado por la matriz equivalente. Sin embargo, para 
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tener acceso a la información en la cadena se precisa un procedimiento 
más complejo que la simple referencia a un subíndice de una matriz. 

En primer lugar, necesitamos saber en qué sección de la cadena están 
contenidos los datos de los monstruos requeridos; a continuación, 
precisaremos saber qué elemento de datos en esa sección se requiere y 
finalmente, tenemos que transformar los datos de la cadena en datos 
numéricos que se puedan utilizar por el programa. Si estamos interesados 
por el valor de ataque de Hulk, por ejemplo, necesitamos la sección 2 (una 
subcadena de tres caracteres), el elemento 3. Tenemos que buscar a lo 
largo de la cadena en grupos de tres caracteres a la vez hasta que 
lleguemos al segundo grupo y luego, buscar dentro de ese grupo hasta 
encontrar el tercer elemento. El Spectrum BASIC nos permite generar una 
función de cadena que pueda realizar esta tarea; otras versiones de BASIC 
requiriría una serie de bucles. La función correspondiente se podría definir 
como: 


DEF FN K$(MS,M,I) = MS((M—1) *x3) +1) 


M es el número del monstruo e 1 es el número del elemento. Cuando 
deseemos encontrar el valor de ataque de Hulk, escribiremos: 


LET J$=FN K$(,2,3) 


Pero, entonces tendríamos que realizar el proceso de transformar el 
carácter que acabamos de extraer en un número mediante el empleo de 
Val, por lo que podríamos hacer más compleja la función en primer lugar: 


DEF FN K(M,D)=VAL(MS,(M—1) *3) +1 
y utilizarle escribiendo: 
LET J=FN K(Q,3) 


Ello podría no parecer demasiado complejo. Sin embargo, la escritura 
de dicha cadena es más difícil. Si quisiéramos modificar el valor de ataque 
de Hulk dentro del programa y estuviera almacenado en la matriz M, 
solamente necesitaríamos escribir: 


LET M(2,3) = x 


en donde x es el nuevo valor. Sin embargo, con el empleo de una cadena 
de caracteres tenemos que encontrar el elemento correcto, borrarlo e 
insertar el nuevo elemento, habiendo transformado x en un carácter. De 
nuevo, ello se podría hacer mediante unas pocas líneas del programa 
utilizadas como una subrutina, pero las funciones también pueden hacer 
esta tarea: 


DEF EN AS(M$,M,I) = MS(1 TO ((M—1) x3) +1-1) + STRS(X) + 
MS((M—1) x3) +1 +1 TO LEN(M9)) 


No tenemos necesidad de definir todos los parámetros para esta función 
porque algunos están definidos ya en el resto del programa. Así, MS es la 
cadena de caracteres que estamos utilizando, M es el número del 
monstruo, 1 es el número del elemento que deseamos cambiar y X es el 
nuevo valor. 

Lo que hace esta función compleja es tomar la cadena a la izquierda 
del elemento requerido y añadirla a la versión de cadena del nuevo valor, 
agregando al resultado el resto de la cadena más allá del valor antiguo. El 
elemento antiguo se suprime de la cadena seleccionando mitades antes y 
después del mismo, mientras que el nuevo valor se inserta entre ellas, en el 
lugar equivalente. 

Este es un procedimiento complejo, pero probablemente es digno de 
consideración si se está manipulando grandes cantidades de datos y la 
memoria disponible es un factor crucial. Sin embargo, el almacenamiento 
de datos de esta forma tiene otros dos defectos. En primer lugar, en una 
matriz el acceso aleatorio significa que lleva prácticamente el mismo 
tiempo encontrar cualquier elemento de datos (DATA), prescindiendo de 
si está situado al principio, al final o en la parte media de la matriz. Sin 
embargo, para procesar la información en una cadena, sobre todo si se 
está utilizando bucles anidados pero incluso con funciones que tengan 
acceso a la información de forma secuencial, cuanto más lejos está la 
información deseada en la cadena, tanto más larga será la búsqueda. En 
consecuencia, es conveniente almacenar los datos que se utilizarán con 
más frecuencia al principio de dicha cadena y los utilizados con menor 
frecuencia al final de la misma. 

Con el fin de que las funciones actúen de forma adecuada, la cadena 
debe mantener la misma longitud y los datos no se pueden desplazar de 
posición. Ello significa que la cadena original ha de ser de la longitud 
máxima necesaria por el programa y todas las posiciones en ella deben 
rellenarse. Por consiguiente, si los valores de los elementos particulares es 
probable que se hayan de cambiar de 1 a 20, cada ranura en la cadena ha 
de ser tratada como una ranura de dos posiciones desde el principio. Ello 
es cierto incluso si solamente un elemento en la cadena tuviere dos 
caracteres de longitud. Así, en nuestro ejemplo la cadena sería ahora: 
“010203020304010302” y todas las funciones tendrían que actuar sobre los 
elementos de dos caracteres de longitud en lugar de hacerlo sobre los de 
uno. 

Una forma de resolver este problema, si no tenemos presente que 
nuestros datos son algo limitados, es utilizar caracteres en lugar de 
números en la cadena. Cada carácter en un juego de caracteres de una 
computadora tendrá un código distintivo. Para el Spectrum, estos son 
proporcionados por la función CODE; para otras máquinas, ASC desem- 
peña la misma función. Habida cuenta de que la mayor parte de estos 
códigos son números de dos o de tres dígitos, almacenar una cadena de 
caracteres únicos es lo mismo que almacenar una serie de números entre 
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32 y 255 si examinamos los códigos de los caracteres más bien que sus 
valores de visualización. 


Lamentablemente, los códigos de hasta 32 suelen ser códigos de 
control y son difíciles de manipular en dichas cadenas, por lo que si 
deseamos un margen de números que comience en 1, tendremos que restar 
32 a través de la tabla. Asimismo tendríamos que evitar el carácter de 
“pues podría dar lugar a problemas con la manipulación de las cadenas, 
por lo que comenzamos nuestro margen útil en CODE35, lo que nos 
proporciona un margen real de 1 a 221. No obstante, ello es una mejora 
útil en la ardua manipulación que implica las cadenas de números. 
Nuestra cadena de muestra sería ahora: “H$%5%8.H %,$”. Para decodifi- 
carla, utilizamos una rutina como la anterior, pero sustituyendo a VAL 
por CODE. Por ejemplo, para representar a 1 debemos añadir 34 a 1 y 
luego transformarle en el carácter equivalente de ese número utilizando 
CHR$. CHRS$(35) es $. 


Para la escritura de la cadena, utilizamos la función A$ anterior, 
sustituyendo también aquí VAL por CODE. En ambos casos, debemos 
recordar que hay que restar o sumar 34 para transformar el margen real 
en el margen permitido. 


Nuestro método final de almacenamiento de datos implica la manipu- 
lación directa de las sentencias DATA. Acaso haya observado que al 
introducir nuestros datos en una matriz, anteriormente en esta sección, 
hicimos la lectura de los datos a partir de las sentencias correspondientes. 
En cierto sentido, ello significa que los mismos datos se retienen dos veces 
en el programa: una vez en la matriz y una vez en los datos. La razón de 
que se utilicen matrices es que se pueden manipular con facilidad, 
mientras que la manipulación de las cadenas puede ser más compleja y las 
sentencias de datos no se pueden manipular en absoluto dentro de un 
programa BASIC normal. 

En consecuencia, los datos se pueden leer a partir de las sentencias 
DATA pero no se pueden escribir en ellas. Si nuestro programa es tal que 
no tenemos necesidad de manipular estos datos (o manipularles sólo 
temporalmente y no almacenar los resultados) podríamos encontrar que 
una matriz es un desperdicio de tiempo y de codificación y que basta con 
efectuar la lectura de las sentencias DATA. En otros capítulos se tratarán 
algunas aplicaciones de lo anterior. Sin embargo, el método es de una gran 
sencillez. 

A cada monstruo se le asigna su propia sentencia de DATA en una 
línea separada del programa, reteniéndose los datos en un orden conocido 
que corresponde al orden fijado de nuestra matriz o de nuestra cadena. A 
continuación, para encontrar el elemento de información particular que 
deseamos nos bastará restaurar (RESTORE) el puntero de datos (DATA) 
al número de línea correcto y efectuar la lectura (READ) de los datos para 
una sola variable hasta que hayamos efectuado la lectura del número 
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2.—Williams 


correcto. Si los datos de nuestro monstruo Hulk se almacenan del modo 
siguiente: 


1010 DATA 2,3,4 
la siguiente rutina corta encuentra el valor de ataque, 


50 RESTORE 1010 

60 FOR I = 1 TO 3 

70 READ A 

80 NEXT I 

90 PRINT “EL VALOR DE ATAQUE DE HULK ES”; A 


Una vez examinado cómo podríamos almacenar las características del 
monstruo, veamos brevemente cuáles podrían ser esas características. 

Suele ser preferible asignar al monstruo una gama de capacidades así 
como un margen de valores. En un juego fantástico, ello significa 
dispositivos tales como proporcionarles poderes mágicos, formas especia- 
les de ataque o de comportamiento y descripciones diferentes. En un juego 
más realista, tal como una aventura en el Salvaje Oeste, se podría 
desarrollar personalidades para diferentes “monstruos”, así como propor- 
cionarles un margen de destrezas (tales como saber manejar un lazo 
corredizo, disparar, luchar, beber, jugar, etc.). Para los monstruos 
inteligentes dichas diferencias son cruciales. 

Por supuesto, el objetivo es dar variedad al juego, de modo que el 
jugador no tenga una idea exacta de lo que ha de esperar y siempre 
encuentre algo nuevo en un juego particular. Cualquier característica que 
pueda modificar la interacción jugador-monstruo es digna de considera- 
ción para su incorporación. Quizá fuera interesante que los diferentes 
monstruos se comunicaran de formas diferentes, que el jugador pudiera 
hacerse amigo de algunos monstruos ofreciéndoles regalos o mediante un 
diálogo suave y que luego le acompañe a través de la aventura. También 
pudiera ser interesante que los monstruos fueran de diferentes edades, 
sexos, altura, pesos o religiones y que, por consiguiente, pudieran ser 
sensibles a ciertas clases de observaciones e incluso que algunos monstruos 
tuvieran otros amigos o enemigos dentro de la propia aventura y 
finalmente, que algunos monstruos conocieran información acerca de 
otros. Casi cualquier característica que se pueda encontrar en un hecho de 
la vida real o en una novela se pueden programar en un juego establecien- 
do una rutina adecuada y una base de datos correspondiente. 

En el Capítulo 10 encontrará una rutina corta que debe estimular su 
imaginación en este sentido. Lo que es importante recordar. Sin embargo, 
al plasmar cualquiera de estas ideas en un código es que debe conseguirse 
un equilibrio entre la cantidad de programa (memoria, tiempo, codifica- 
ción) que se requiere y el efecto del monstruo en el juego. Si la mitad del 
programa se utiliza simplemente para generar un monstruo inteligente, 
encontrado en el recinto 100, el jugador es improbable que sepa apreciar 
las complicaciones de su diseño. 
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2.5 Objetos 


En un programa de aventuras, los objetos son de dos clases: portátiles y 
fijos. Los objetos portátiles se pueden desplazar de un lugar a otro en el 
juego, pero los objetos fijos no pueden hacerlo. En términos del juego, ello 
significa que el objeto fijo es esencialmente una característica de una 
localización particular o lo que es lo mismo, un aspecto de su descripción. 
Desde el punto de vista del jugador, no hay ninguna diferencia entre la 
salida “está en un túnel oscuro y maloliente”” y la salida “hay un 
candelabro de latón colgando de la pared”, si ninguna entrada de su parte 
puede tener ningún efecto sobre la descripción. Por tanto, desde ahora 
en adelante, utilizaremos la palabra “objeto” para referirnos solamente 
a elementos que se puedan desplazar desde un lugar a otro y considerare- 
mos objetos fijos a las características de localizaciones particulares. 

Los objetos sirven para diversos fines en los juegos de aventuras. En lo 
que respecta a la psicología del jugador, proporciona las recompensas 
inmediatas (recordará que anteriormente analizamos el juego como siendo 
una estrategia concebida para recibir recompensas). Dicho de otro modo, 
cada vez que el jugador encuentra primero un objeto puede llevarlo 
consigo o manipularlo de alguna manera, que haya calificado como una 
pequeña victoria o una parte “ganada” del juego. 

En lo que respecta al realismo narrativo de la historia, que constituye 
dicho juego, el transporte de cosas es un aspecto fundamental de un 
trazado, aunque, a veces, la cosa transportada es una información o una 
capacidad en lugar de ser un objeto propiamente dicho. 

En términos de la estructura del programa, el tener objetos es una de 
las formas más sencillas de añadir complejidad y variedad a nuestro juego. 
Después de todo, un pequeño juego de 10 localizaciones y 10 objetos 
podría dar 100 sucesos posibles en el juego; un juego grande de 1.000 
localizaciones y 100 objetos podría dar 100.000 sucesos, lo que es 
probablemente más de lo que podría resolver el más especializado de los 
aventureros. 

Un objeto puede ser que no tenga ningún significado en el juego, 
siendo alguna especie de cosa inútil, elemento desperdiciador de tiempo u 
obstáculo, pero suele tener una finalidad más específica. En el juego de 
enigmas, normalmente formará parte integrante de la solución al mismo; 
v.g., para encontrar la fórmula perdida, el aventurero debe penetrar en un 
recinto con una puerta cerrada, por lo que debe encontrar y llevar la llave. 
En el juego de combate, los objetos suelen mejorar las capacidades del 
protagonista haciéndole más eficiente en algún otro aspecto del juego. Por 
ejemplo, el hallazgo de un escudo puede mejorar el valor de la defensa y, 
por consiguiente, la probabilidad de sobrevivir en combates futuros. El 
conseguir una porción mágica puede aumentar la fortaleza del protagonis- 
ta y, por consiguiente, su valor de ataque y (o) la facilidad para 
transportar otros objetos. 


25 


Sin embargo, algunos inconvenientes pueden acompañar a tales 
ventajas. En los enigmas, se da con frecuencia el caso de que el hecho de 
haber encontrado un objeto necesario para superar una dificultad, puede 
generar otro problema. El descubrimiento de polvo de oro puede ayudarle 
a sobornar a alguien, pero le plantea el problema de eludir a los 
salteadores. El encontrar un hacha de doble filo añade una valoración de 8 
a su ataque, pero hace que no pueda llevar un escudo, por lo que su valor 
de defensa disminuirá en 2. 

Desde el punto de vista de la programación, por consiguiente, un 
objeto puede considerarse como un indicador, que señaliza que se cumple 
una condición particular (el objeto se ha encontrado) y, por tanto, se 
permiten algunas consecuencias, o bien, se puede considerar como una 
función que actúa sobre una o más de las variables del protagonista, 
normalmente aumentando su valor. Ello significa que los objetos pueden 
representarse en nuestro programa de varias formas y que un solo objeto 
suele tener varias representaciones. También significa que lo mismo que la 
construcción de los monstruos depende de la estructura del programa 
total, y particularmente de la estructura del protagonista, los objetos 
deben considerarse como extensiones del protagonista, modificándole 
según las normas incorporadas y haciendo posible la realización de ciertos 
desarrollos en el juego. 

Veámoslo con un ejemplo. Supongamos que deseamos concebir un 
juego en el que el protagonista sea un explorador del siglo XIX en Egipto. 
Uno de los problemas fundamentales que podemos plantear al aventurero 
es el descifrado de los jeroglíficos (una buena oportunidad para algunos 
gráficos interesantes). Podríamos desear que partiera con unos conoci- 
mientos mínimos en el descifrado de los jeroglíficos, pero que fuera capaz 
de ir aumentando su capacidad. Supongamos que comienza con D=10, lo 
que le da una posibilidad del 10% de entender cualquier jeroglífico que se 
encuentre. Sin embargo, si se encuentra la Piedra de Rosetta dispondrá de 
un diccionario de la mayoría de los signos existentes en los jeroglíficos, 
por lo que su posibilidad de descifrarlos habrá aumentado a un 60%. 

Dichas ideas se pueden complicar fácilmente sin mucha codificación 
suplementaria. En el interior de una pirámide o de una tumba, debido a la 
oscuridad, la posibilidad descenderá a una cuarta parte de su valor 
normal, al menos que se utilice una lámpara, en cuyo caso, será una mitad 
del valor normal. Si el jugador es capaz de descifrar un jeroglífico mágico, 
su posibilidad llegará a ser del 100 %, durante un período limitado, pero si 
comete un sacrilegio caerá al 5%. Lamentablemente, la piedra es muy 
pesada, por lo que no se puede transportar al mismo tiempo que cualquier 
tesoro y si una momia ve la piedra atacará inmediatamente a su portador. 

De esta forma, se elabora un potencial nárrativo complejo sobre la 
base de unas pocas variables simples y cada elemento está relacionado con 
todos los demás. El monstruo y el objeto están relacionados (la momia y 
la piedra) y la capacidad del personaje y el objeto también están 
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interrelacionadas. La situación puede afectar a todos ellos y el éxito puede 
conducir a otro éxito posterior. No obstante, existen posibles penalizacio- 
nes y trampas y la propia recompensa podría ser un riesgo elevado (tal 
como el empleo satisfactorio de la piedra para leer un maleficio que se 
activará por este hecho). 

Como en el caso de los monstruos es, pues, importante que los objetos 
no solamente tengan sentido en términos de la programación, sino que 
también lo tengan en lo que respecta al trazado y al juego propiamente 
dicho. Las aventuras bien concebidas son una serie de acciones arbitrarias. 
Tampoco deben ser una serie de acciones muy estructuradas que parezcan 
ser arbitrarias. Los juegos bien concebidos, desde el punto de vista del 
jugador, no son aquellos que están bien escritos, sino los que parecen estar 
bien escritos. El efecto de un juego y su apariencia suele ser más 
importante que su contenido o naturaleza real. 


TECNICAS EN LA 
3 PLANIFICACION DEL JUEGO 


3.1 Estructuras 


Casi todos los juegos de aventuras se pueden reducir a varios elementos 
claves y las relaciones entre dichos elementos se ponen de manifiesto 
mediante un sencillo diagrama de flujo. En este capítulo, examinaremos 
cada uno de estos elementos básicos y el diagrama de flujo del conjunto, 
de modo que en el siguiente capítulo estas ideas generales se puedan 
plasmar en un mapa y luego en un juego. Cada uno de los siguientes 
capítulos toma uno o más de estos elementos y los examina con detalle, 
explorando algunas de las formas diferentes en que pueden manipularse. 

Los elementos variarán ligeramente según la máquina particular 
utilizada (v.g., si tiene gráficos de alta resolución o de color), pero, al nivel 
más general, todos los juegos de aventuras tienen cada uno lo siguiente: 
alguna forma de entrada/salida, constituida por un componente textual (lo 
que se escribe en la unidad de presentación visual, tal como una 
descripción de un recinto y de su contenido), un componente visual (quizá 
una ilustración gráfica de ese recinto o una señal de aviso intermitente), un 
componente de sonido (explosiones mágicas, silbidos y efectos especiales), 
junto con tres estructuras: La estructura del juego (cuáles son las reglas de 
juego y cómo han de llevarse a cabo), las estructuras de la narración o del 
enigma (qué es lo que el jugador pretende hacer en el juego) y la estructura 
del programa (cómo cada uno de los elementos anteriores se agrupan en 
una forma que una computadora pueda entender). Este modelo básico de 
un juego se muestra en la figura 3.1. 

Estas son las siete áreas que hemos de considerar en la etapa inicial del 
diseño de nuestro juego. Las ideas claras y originales en esta primera fase 
tendrán su recompensa más adelante. Por el contrario, si solamente 
tenemos idea sobre lo que es el juego sin considerar cómo aparecerá ante 
el jugador o si decidimos que vamos a diseñar un juego con el empleo del 
reconocimiento de la expresión oral pero sin que tengamos ninguna idea 
sobre como se jugará, antes o después nuestra codificación llegará a una 
interrupción total o se precisará grandes cantidades de nueva escritura o, 
si incluso se llega a construirlo, el resultado será un juego sin atractivo 
ninguno. Por supuesto, no se debe planificar cada una de estas áreas en 
una forma que sea completamente independiente de las demás. Resultan 
adecuadas las abstracciones como ayuda al diseño, debiendo añadirse 
frases no completamente cerradas. Más adelante en este capítulo, exami- 
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Estructura Estructura 
del juego de la narración 


Estructura 
del programa 


Textual Sonido 


Entrada/salida 


Ejecución 


real 


Figura 3.1 


naremos algunas estrategias de diseño que se pueden utilizar, pero, en 
primer lugar, haremos un breve examen de cada uno de los bloques de la 
figura 3.1, con el fin de encontrar la clase de contenido que ellos pueden 
tener y las decisiones que sean necesarias para su desarrollo. 


3.2 Estructura de la narración 
Muchos juegos de aventuras comienzan con una idea para un escenario o 
línea de narración particular. ¿Sería buena idea tener un juego sobre el 


descenso al interior de un volcán con miras a un viaje al centro de la 
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tierra? ¿Cómo sería un juego en el que los jugadores navegaran con la 
Kontiki a través del Océano Pacífico? Podría desear que hubiera un juego 
en el que se pudiera desplazar a través del universo para vivir la historia de 
una carrera antigua. Sin embargo, aunque tenga una inspiración inicial, 
puede ser que no sepa cómo plasmarla en una descripción que se pueda 
codificar para la microcomputadora. Después de todo, ha habido mucha 
gente que ha intentado escribir narraciones y solamente unos pocos han 
obtenido los resultados apetecidos. 

No necesita ser un gran novelista para escribir una narración, describir 
un escenario o establecer un rompecabezas, que pueda llegar a ser la base 
de un programa. Todo lo que necesita recordar son dos cosas: 


l. Una narración es una serie de sucesos enlazados en la que un 
protagonista (o un grupo de protagonistas) está inmerso en alguna 
forma. 

2. Un suceso que está constituido por un lugar, un tiempo particular, uno 
o más protagonistas, uno o más objetos y algunas posibles acciones o 
consecuencias. 


Ahora podemos elaborar nuestra estructura de la narración. Escribi- 
mos, bien sea de forma descriptiva, bien sea de forma de diagramas de 
flujos, todos los sucesos que nos gustaría incluir y como ello se podrían 
enlazar. Ello trae consigo, a su vez, tomar una decisión sobre el 
protagonista o los protagonistas, como ellos podrían cambiar (v.g., 
hacerse ricos, resultar lesionados, aprender a volar, etc.), qué lugares o 
localizaciones habrá, qué período se vivirá (las guerras napoleónicas, el 
futuro lejano, tiempos prehistóricos), qué clase 'de objetos podrían 
encontrarse o utilizarse (naves espaciales, cofres de tesoros, mapas, armas, 
caballos, embarcaciones, reliquias religiosas) y qué clases de acciones 
pueden tomarse si el protagonista puede ser asesinado, puede hablar o 
escribir, puede desplazarse de un lugar a otro, si los objetos se pueden 
transportar y si fuera así cuáles, si han de incluirse dispositivos mágicos o 
de ciencia ficción). Al final de este capítulo encontrará una lista de 
posibles líneas de narración que no se han utilizado mucho, o nunca, en 
juegos de aventuras para que las adapte a sus propios juegos. 

Asimismo, tenemos que decidir sobre la forma o las formas en que 
pudiera acabar la narración. ¿Sólo acabará cuando se haya asesinado al 
protagonista principal? ¿Habrá algún trabajo que realizar o algún proble- 
ma que resolver? ¿Habrá de encontrarse algún tesoro o habrá que alcanzar 
un nivel social particular? Estas interrogantes se relacionan evidentemente 
con la estructura del juego, porque las formas en que pudieran finalizar 
nuestra narración o nuestro escenario están relacionadas con la forma de 
ganar o de perder el juego. 

Para ilustrar cómo podemos hacerlo, damos a continuación la estruc- 
tura básica de una sencilla narración. 

El Jefe Búfalo de Hierro (el personaje principal) debe conducir a su 
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tribu a nuevos terrenos de caza antes de que llegue el invierno. La tribu 
puede pasar a través de las montañas, de los bosques y de las llanuras (las 
posibles localizaciones) en donde pueden encontrar lobos, osos, a los 
Cuchillos largos o a colonos (éstos son los demás protagonistas) y pueden 
encontrar también caballos salvajes, búfalos y un tomahawk mágico 
(objetos). Puede elegir entre atacar, huir o parlamentar con los demás 
protagonistas, domesticar o cazar los caballos salvajes o los búfalos, llevar 
o dejar el tomahawk y tendrán que comer una cierta cantidad de 
alimentos cada semana (posibles acciones). Se les podría dar una alimen- 
tación suplementaria, establecer una corta escasez o ser atacados por otros 
personajes (acciones adicionales). Las posibles consecuencias son que la 
tribu muera de hambre, llegue a perderse en el desierto, todos sean 
asesinados por los hombres blancos y los animales salvajes, se rebelan 
contra el jefe y le arranquen la cabellera o encuentren nuevos territorios de 
caza (formas de finalizar la narración). A continuación, tendremos que 
decidir sobre cómo enlazarlos y cómo encajarles con las otras seis áreas 
básicas del programa. Por ejemplo, ¿cuáles son las posibilidades de 
encontrar a los colonos en el bosque? ¿Habrá ilustraciones gráficas de 
cualquier combate? ¿Cómo se desplazará la tribu de un lugar a otro? 


3.3 Estructura del juego 


Todos los juegos tienen esencialmente la misma estructura: El jugador 
hace un movimiento, se calcula las consecuencias de ese movimiento y si el 
jugador ha ganado o perdido el juego éste finaliza; de cualquier otro 
modo, ese jugador u otro jugador hace otro movimiento. En el caso de un 
juego de aventuras, en raras ocasiones hay movimientos en el sentido 
tradicional, es decir, un movimiento como los del juego de ajedrez. Lo que 
sucede, por el contrario, es que al jugador se le presenta periódicamente 
una serie de elecciones que representa las clases de acciones que su 
personaje podría tomar en el tipo de mundo representado en la narración. 
La elección realizada es el “movimiento” y sus consecuencias serán algún 
efecto sobre el personaje (es envenenado) o en el mundo en que vive 
(rompe una puerta) o ambas cosas (la nave espacial explota, arrojando al 
personaje al espacio). 

Ello se puede representar por un diagrama de flujo sencillo, tal como se 
ilustra en la Figura 3.2. 

Las clases de opciones, elecciones y modificaciones dependen de la 
estructura de la narración que hayamos elegido, pero el diagrama de flujo 
básico sigue siendo el mismo. Sin embargo, evidentemente hay variaciones 
que se pueden elegir; de no ser así, los juegos de aventuras serían 
aproximadamente idénticos y bastante aburridos. Por ejemplo, una de las 
opciones puede llevar inmediatamente a una elección de opciones adicio- 
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l. Las opciones de los personajes son objeto de impresión. 
. El jugador elige una opción. 

. Se calcula el efecto de la elección. 

. El personaje se modifica si fuera necesario. 


. El ámbito del juego se modifica en caso de necesidad. 


Do ón Bb un 


. Si el juego ha concluido, ha de pasarse al número 7; de cualquier otro 
modo, se pasa al número 1. 


7. Finaliza el juego. 


Figura 3.2 


nales sin ninguna modificación del protagonista ni se dé ámbito. Al 
jugador se le podría presentar la siguiente lista de opciones: 


1. ATAQUE 
2. HIPERESPACIO 
3. INVESTIGACION 


Si se elige la opción de ATAQUE, una segunda serie de elecciones se le 
puede dar inmediatamente, cada una de las cuales constituye una subcate- 
goría de ataque: 


1. DISPARO DE MISILES 
2. DISPARO DE TORPEDOS 
3. ATACAR CON UN ARMA AL OPONENTE 


Dicha especificidad creciente puede proseguirse de forma indefinida hasta 
llegar al límite de la capacidad de la microcomputadora utilizada. Muchas 
microcomputadoras solamente permiten un número limitado de subruti- 
nas incorporadas, lo que podría restringir esta clase de especificidad 
“anidada”. 

Una segunda variante de juego implica el efecto que la elección tiene 
sobre el jugador más bien que con respecto al personaje o a su ámbito. Por 
ejemplo, una solicitud de nuevas instrucciones o para imprimir el estado 
actual del personaje es una parte de la estructura del juego que no tiene 
ningún efecto sobre el juego propiamente dicho. Sin embargo, sería 
perfectamente posible para dichas elecciones afectar al juego. Por ejemplo, 
cada vez que un jugador pide instrucciones, se podría reducir la variable 
de inteligencia de su personaje. Esta clase de modificación hace más 
interesante el desarrollo del juego y esa es una consideración primaria 
cuando se concibe un juego. Un juego atractivo es aquel que es lo 
suficientemente dificil para entretener, pero lo suficientemente fácil para 
su comprensión. Los juegos abstractos, tales como Otelo y Ajedrez, son de 
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gran aceptación por la sencilla razón de que son fáciles de aprender pero 
difíciles de jugar bien. De forma análoga, la estructura del juego de una 
aventura debe hacerle fácil de jugar pero difícil de conseguir un resultado 
satisfactorio. 

Esta es la razón de que existan dos amplias categorías de juegos de 
aventuras: el juego de enigmas y el juego de combate. El primero 
construye la estructura del juego sobre la base de un enigma o de una serie 
de enigmas, cada uno de los cuales debe resolverse para conseguir vencer 
en el juego. En este caso, son objeto de prueba la inteligencia y la 
imaginación. El segundo tipo de juego es más próximo al juego de acción 
rápida o al juego bélico de sobremesa. La estructura de juego depende de 
la táctica y de la estrategia de combate entre el protagonista y el 
monstruo, teniendo que tomar decisiones con rapidez y con consecuencias 
tales como las heridas que tengan un efecto sobre las batallas subsiguien- 
tes. Este tipo de juego prueba las reacciones y la planificación táctica. El 
juego de aventuras ideal debe combinar estos dos procedimientos, impli- 
cando al jugador en elecciones que sean intelectualmente desafiantes en la 
forma más amplia posible, así como en reto de reflexiones rápidas y las 
aptitudes tradicionales estratégicas y tácticas de los juegos de tablero. 

Una tercera variante es modificar las posibles opciones y consecuencias 
y (o) hacerles que se afecten mutuamente. En un juego bien concebido, 
una elección hecha en los primeros movimientos puede tener un efecto 
notable sobre las elecciones planteadas mucho más adelante. Por consi- 
guiente, parte de la estructura del juego debe ser una descripción de cómo 
se relaciona entre sí las elecciones. Por ejemplo, si en el juego de ajedrez 
elige colocar todos sus peones en los cuadros negros facilitará el movi- 


Conocimiento 


Nivel social 


Figura 3.3 
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miento de su alfil blanco pero dificultará el movimiento de su alfil negro. 
Nuestro juego puede implicar el diseño de una nave espacial. Si el jugador 
elige una gran cantidad de armamento, tal vez se vea obligado a diseñar 
una nave lenta. O bien, supongamos que un jugador encuentra una varita 
mágica. A corto plazo, ello puede serle de utilidad, pues podrá realizar 
encantamientos, pero quizá se vea condenado a destruir a su propietario 
en un recinto con engendros devoradores, lo que supondría una “desven- 
taja”” a largo plazo. 

En particular, al diseñar una estructura de juego debemos tomar una 
decisión sobre cómo actuará cada opción. Ninguna elección en un juego 
de aventuras debe conducir automáticamente al éxito. Una elección debe 
llevar al éxito solamente si se hace junto con otras elecciones correctas 
(v.g., debe elegir el arco negro pero solamente la flecha blanca) o debe 
existir solamente una posibilidad de éxito representada por una curva de 
función de su probabilidad. Dichas curvas están en el “corazón” de 
muchos juegos. Por ejemplo, supongamos que nuestro juego implicaba el 
desplazamiento del personaje, en su escala social, desde el campesino al 
rey y cada desplazamiento representaba un año en su vida. A medida que 
va ascendiendo en su nivel social aumentará sus conocimientos. Ello lo 
podríamos representar por la curva de la Figura 3.3. Sin embargo a 
medida que se hace más viejo irá disminuyendo su inteligencia, tal como 
se ilustra en la Figura 3.4. 

Supongamos que su posibilidad de pasar al siguiente nivel social 
depende, en la misma medida, de los conocimientos y de la inteligencia. 
Entonces, la curva que relaciona a la edad con la posibilidad de elevar su 
nivel social sería la representada en la Figura 3.5. 


Inteligencia 


Edad 
Figura 3.4 
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Como el crecimiento en edad es uniforme (un año cada vez) pero su 
nivel social es variable por lo que el mantenimiento de sus posibilidades al 
50%, depende de que haya tenido éxito con anterioridad (lo que inicial- 
mente será sólo del 50% del tiempo), la curva real de posibilidades de 
éxito en la elevación del nivel social a la medida que avanza el juego 
tendrá un aspecto muy similar al que se representa en la Figura 3.6; es 
decir, inicialmente, la edad y el nivel social se cancelan entre sí determi- 
nando la posibilidad de elevar el nivel social, pero a medida que transcurre 
el tiempo se hace cada vez más importante el factor de la edad. 

Toda probabilidad en un juego se puede dar en la forma de una curva 
como la anteriormente indicada y la posibilidad de ganar el juego 
dependerá de la curva que sea un sumario de la combinación de todas las 
curvas. Ello puede implicar algunos cálculos matemáticos muy complejos. 
Sin embargo, no es necesario llegar tan lejos en el cómputo de todas las 
curvas de todas las funciones en nuestro juego, sobre todo si la suerte (el 
factor aleatorio) desempeña un papel importante. Lo que tenemos que 
asegurar es que elijamos funciones, fórmulas y algoritmos que (1) tenga 
sentido en el mundo que estamos creando y (2) nunca produzca un 100 % 
de certidumbre. Debemos asumir las consecuencias de elecciones con 
pocas muestras y probar las funciones más frecuentemente utilizadas en 
otro juego antes de que decidamos definitivamente incorporarlas a dicho 
juego. Siempre es posible ajustar las fórmulas más adelante, pero es 
mucho mejor tener una estructura equilibrada que se haya elaborado 
desde el principio de modo que no tengamos que recurrir a “chapuzas” 
que podrían trastornar el juego completo. 


Posibilidad 
de elevar el 50 
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Figura 3.5 
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Encontrará algunas sugerencias adecuadas para funciones en puntos 
diferentes en este libro cuando examinemos detenidamente cada caracte- 
rística particular. 


3.4 Entrada/salida 
SONIDO 


Muchas microcomputadoras no tienen medios acústicos y otras lo tienen 
muy deficientes, por lo que puede ser que no necesite incorporar sonido a 
su juego. Ciertamente es menos esencial para los juegos de aventuras que 
para los juegos de acción rápida, por lo que no resulta fundamental. Sin 
embargo, algunas microcomputadoras tienen excelentes medios acústicos 
y hay algunos empleos del sonido que pueden realzar un juego de 
aventuras (ver Capítulo 8), por lo que si decidimos utilizar sonido 
debemos hacerlo al principio del proceso del diseño para hacer máximo su 
empleo efectivo, como con cualquier otra característica del juego. 

La decisión principal que debemos tomar inicialmente es si el sonido 
ha de ser una parte integrante del juego, proporcionando información que 
no esté disponible en cualquier otra forma (tal como el empleo de pistas 
musicales como parte del enigma) o simplemente un realce que no 
contenga características esenciales (v.g., una sintonía ejecutada al princi- 
pio y al final de cada juego). Naturalmente, el sonido se puede utilizar en 
ambas formas en un solo programa. En el caso de sonido no esencial 
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siempre se puede añadir durante las etapas finales de codificación, cuando 
sabemos de cuántas memorias disponemos y qué secciones del juego 
necesitan dicho realce. Sin embargo, los sonidos esenciales se deben 
incorporar al diseño lo antes posible como toda la demás información 
fundamental de modo que podamos ver cómo encajarle en la estructura 
total y que seamos capaces de desarrollar efectos acústicos en paralelismo 
con el resto del programa preferiblemente a añadirlos de forma superficial. 


VISUAL 


A no ser que su aventura solamente proporcione una copia de salida 
impresa (como en los juegos por correo, tratados en el Capítulo 11), 
siempre habrá una componente visual. La información para cada turno de 
jugada se visualizará en la unidad de presentación visual (VDU). Puede ser 
completamente gráfica, en cuyo caso, será una aventura del tipo de acción 
rápida o puede ser completamente textual. Con la generación actual de 
microcomputadoras, parece ser antieconómico la no disposición de una 
salida gráfica, pero, por otra parte, los elementos gráficos pueden exigir la 
utilización de una gran cantidad de memoria y las aventuras suelen 
requerir la mayor cantidad de memoria posible para su lógica. El juego de 
aventuras tradicional es completamente textual, pero existe una demanda 
creciente de juegos que utilicen gráficos en tiempo real, color, alta 
resolución, ilustración tridimensional. A medida que la memoria se hace 
más barata, dichos desarrollos se harán más viables. 

Por consiguiente, es conveniente que haga su primer juego de aventu- 
ras principalmente textual, pues ello simplifica el trabajo, pero dejar 
reservado uno o dos K octetos de memoria para experimentación con 
realce gráfico, tal como en títulos o avisos. ] 

Si, por el contrario, queremos ilustrar cada recinto y cada monstruo o 
bien, utilizar alguna forma de animación, necesitaremos mucha más 
memoria, lo que limitará la magnitud y el alcance del programa. Existen 
formas de utilización de ficheros en discos o en casetes que permiten el 
almacenamiento de gráficos fuera de la memoria de acceso aleatorio 
(RAM), con lo que se optimiza ambos ámbitos (pero haciendo más lenta 
la ejecución del programa). Para un examen de estas características 
funcionales, ha de consultarse el Capítulo 11. 

De momento, necesitamos decidir: 


1. Si deseamos utilizar elementos gráficos. 
2. Para qué finalidad. 
3. Cuánta memoria ha de destinarse a tal fin. 


Esencialmente, existen tres tipos de visualización de gráficos utilizados 
en los juegos de aventuras, a saber: 


1. Visualización decorativa, como en títulos, avisos intermitentes, texto 
ilustrado, etc. 
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2. Hustración, como en una imagen del monstruo que el protagonista está 
a punto de atrapar o la visión de lo que se observa al penetrar en una 
nueva localización. 

3. Información esencial, en donde los gráficos contienen información que 
es fundamental para el juego y que no se da en ninguna otra forma, tal 
como cuando se utilizan pistas visuales o cuando se incorpora un 
encuentro de acción rápida. 


El primero de estos tipos de gráficos es más fácil de realizar y puede 
aumentar, en gran medida, la atracción de un juego, pero, hablando en 
términos estrictos, resulta innecesario y por ello se suele omitir. La tercera 
forma es la más interesante, pero también es la más difícil, por lo que nos 
concentraremos sobre todo en la segunda. Siempre debemos intentar 
utilizar una microcomputadora en los límites de sus recursos. Una forma 
de hacerlo es mediante una mezcla inteligente de sonido, elementos 
gráficos y texto que no sea meramente ilustrativo y que no se pueda 
emular en un juego de tablero. 

Lamentablemente, debido a las muchas implantaciones diferentes de 
elementos gráficos, no es posible entrar en gran detalle sobre cómo se 
podría realizar un diseño particular en varios temas. En los capítulos 
sucesivos esbozaremos ideas que se puedan adaptar a su máquina 
particular, pero la mayor parte de los gráficos incluidos en este libro 
utilizan el sistema del Spectrum. Afortunadamente, ello tiene algunas 
similitudes con otros sistemas populares. 

En la planificación de nuestra visualización resulta conveniente dibujar 
inicialmente unos croquis o bosquejos de la clase de visualizaciones que 
deseamos presentar. Aunque sea innecesario que utilicemos las técnicas de 
los profesionales en donde cada toma de la película es dibujada antes de 
que se fotografíe, resulta conveniente hacer un bosquejo de las imágenes 
principales de modo que podamos decidir en dónde encajarán en el 
programa, cómo utilizarán el espacio de pantalla disponible, cómo pueden 
mezclarse con el texto, qué modos de gráficos se utilizarán y si nuestras 
ideas son demasiado ambiciosas para las posibilidades de nuestra má- 
quina. 

Finalmente, necesitaremos trazar todas las presentaciones visuales 
principales en papel de gráfico o en una hoja de trazado especial, pero en 
la etapa de planificación será suficiente unos dibujos a mano alzada. Hay 
que tener presente que para que merezca la pena una ilustración debe ser 
atractiva, pero que un elemento de información visual importante, tal 
como una pista, puede ser simplemente una utilización funcional de los 
elementos gráficos sin que se busque especificamente su estética. Hay que 
recordar también que una de las cosas que hace que un jugador vuelva una 
y otra vez a ejecutar un juego es su aspecto y su “sensación”, por lo que ha 
de prestarse la mayor atención posible a cómo se presenta el juego. 
incluyendo su salida en la pantalla, pues ello puede ser vital. 
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TEXTO 


El texto es la forma más común de entrada/salida utilizada en los juegos 
de aventuras. Necesitamos considerar cómo se utilizará el texto, cómo 
será presentado, cómo será almacenado y cómo será objeto de proceso. El 
arte del diseño de los juegos de aventuras tienen mucho que ver con la 
variedad de la salida del texto y el análisis versátil de la introducción del 
texto. Lamentablemente, el almacenamiento de grandes cantidades de 
texto hace uso de grandes cantidades de memoria y al ser normalmente 
lenta la manipulación de las cadenas en BASIC, ello hace más lento el 
juego. Habrán de conseguirse algunas soluciones de compromiso. 

Hemos de considerar si todas las instrucciones se incluirán en el 
programa o si se describirán en una hoja adjunta; si las órdenes han de ser 
palabras abreviadas o del lenguaje inglés normal, números o simples 
letras; si alguna forma de compactación de datos ha de utilizarse para 
almacenar más texto; si las descripciones han de ser frases completas o 
palabras abreviadas y si es posible utilizar Órdenes que se puedan 
interpretar de formas diferentes. Asimismo, necesitamos decidir cómo 
visualizar el texto y cómo hacerlo en conjunción con cualquier visualiza- 
ción de elementos gráficos. Por ejemplo, si deseamos que aparezcan en la 
pantalla texto y gráficos juntos a través de todo el juego, necesitaremos 
definir “ventanas” de gráficos y texto de alguna clase o incluso varias 
ventanas diferentes para fines distintos (tal como una para actualización 
del protagonista y otra para la elección de acciones posibles). 

Cada uno de los temas de “visualización en pantalla”, “compactación 
de datos” y “procesamiento de textos” merece que se le dedique un libro 
particular, por lo que no podemos tratarlos a fondo en este libro. No 
obstante, se sugerirán varios métodos pertinentes, junto con algunas 
rutinas de codificación en BASIC, que se relacionan con ejemplos 
detallados. Pueden ser objeto de incorporación en puntos pertinentes en su 
propio programa. Sin embargo, en términos esenciales, han de acatarse los 
principios siguientes: 


1. Utilizar algo que ahorre memoria. 

2. Utilizar algo que haga más rápida la ejecución. 

3. Utilizar algo que aumente la variedad del juego. 

4. Utilizar algo que facilite la ejecución del programa y que le haga más 
divertido para el jugador. 


Debido a su importancia fundamental, vale la pena considerar el texto 
extensamente en la etapa de planificación. El procesamiento del texto 
suele ser olvidado por los programadores de BASIC a pesar del hecho de 
que se pueden realizar muchos procedimientos interesantes. Por una parte, 
debemos considerar formas de hacer el juego más atractivo al jugador, en 
lo que respecta a la variedad textual, deletreo correcto, visualizaciones 
fácilmente legibles. Por otra parte, hemos de tratar de incorporar ideas 
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originales para la utilización de texto, tales como hacer juegos de palabras 
con el nombre del jugador, utilizando chanzas en respuestas a errores 
cometidos por el jugador, visualizando texto como fragmentos de perga- 
mino encontrados en diferentes lugares en el juego, utilizando rutinas de 
cifrado que cambien las claves de un juego a otro, generando una serie de 
pistas verbales, rutinas para “conversación” con monstruos que se 
encuentren a lo largo del juego, etc. Algunas de estas ideas se desarrollan 
en los Capitulos 7 y 8. 


3.5 Estructura del programa 


Cuando las ideas sobre la narración, el juego y las formas de entrada y de 
salida, junto con algunos bosquejos de lo que será la visualización, hayan 
sido objeto de clasificación, estaremos dispuestos para comenzar la 
programación. Un juego de aventuras es como cualquier otro programa, 
pero hay algunos aspectos que es conveniente que se les preste atención y 
que pueden modificar sus técnicas de programación normales. 

Probablemente sea muy importante el hecho de que un juego de 
aventuras suele ser largo. Para que sea interesante debe ser variado y 
complejo como una narración/juego/enigma y ello significa que, por ee 
general, será variado y complejo como un programa. La forma más fácil 
de abordar estos tres problemas relacionados de longitud, variedad y 
complejidad es adoptar una estructura modular. La programación modular 
es conveniente por lo general, porque evita la formación de redes 
embrolladas de sentencias GOTO y estimula a los programadores de 
BASIC a adoptar técnicas estructuradas que facilitan la transición a 
lenguajes como Pascal y FORTH. Los módulos nos permiten probar cada 
sección de un programa a medida que lo desarrollemos y también nos 
permite depurar, con mayor facilidad, programas completos. Asimismo, 
se pueden utilizar módulos en programas diferentes con poca o ninguna 
modificación, por lo que una vez que hayamos escrito un juego de 
aventuras no tendremos que empezar desde la nada con cualquier otro. 
Los diseños en este libro son, pues, modulares en su naturaleza y están 
concebidos para un uso versátil. 

¿Qué significa un diseño modular? En términos esenciales, es lo mismo 
que dividir su programa en varias subrutinas, junto con un programa 
principal que realiza la llamada de cada subrutina cuando se requiera. En 
lenguaje BASIC, un programa muy simple podría ser como el que se 
indica en la Figura 3.7. 

La utilización de una serie de subrutinas no es la única forma de 
concebir una estructura modular, pero es una de las más fáciles. Cada 
módulo, o subrutina, tiene una tarea particular. Puede imprimir instruc- 
ciones, calcular combates o visualizar movimientos de naves espaciales. 
Dicha tarea puede ser objeto de llamada una o varias veces por turno de 
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10. GOSUB 1000: REM INSTRUCCIONES 

20  GOSUB 2000: REM INTRODUCCION RUTINA 

30 REM ALTERNATIVAS DE COMBATES 

40 IFA = 1 THEN GOSUB 3000 

50 IFA = 2 THEN GOSUB 3500 

60 IFA = 3 THEN GOSUB 4000 

70 IFA = 4 THEN GOSUB 4500 

80 GOSUB 5000: REM COMBATE 

90 GOSUB 6000: REM SI EL PROTAGONISTA ESTA MUERTO 
PROPORCIONA D = 1 

100 IFD = 1 THEN GOSUB 7000 ELSE GO TO 10 

110 END 


BETO. oronpiiriaimidnion 
7000 REM FINAL RUTINA 


Figura 3.7 


juego. Si se llama solamente una vez, y particularmente solamente una vez 
por juego, no hay ninguna necesidad de introducir el módulo en una 
subrutina. En cambio, puede ser una sección claramente destacada del 
programa principal. Sin embargo, para hacer más patente la flexibilidad y 
la variedad, resulta conveniente que la mayor parte posible de las 
subrutinas sean capaces de que se les llame más de una vez, dependiendo 
de las condiciones existentes. Por ejemplo, la subrutina de combate puede 
ser objeto de llamada si el jugador decide luchar o, más tarde, si el 
monstruo decide luchar o quizá, incluso si ambos desean evitar la lucha 
pero los ““dioses”” (esto es, un número aleatorio) lo deciden de cualquier 
otro modo. 

Si hemos realizado correctamente nuestros diseños preliminares, debe 
haber quedado claro qué módulos necesitará el programa y en qué orden 
se han utilizado. Si no estuviera claro, nuestra primera tarea de programa- 
ción será ponerlo de manifiesto escribiendo todas las ideas que tenemos 
para el juego y enlazándolas entre sí. Existen diversos métodos para 
hacerlo, pero les recomiendo dos de ellos: 


1. El mapa de la mente. 
2. El diagrama de flujo general. 


El mapa de la mente es una forma de generar ideas con enlaces entre ellas. 
El diagrama de flujo es una forma de estructurar ideas de una manera 

lógica y sistemática. 

EL MAPA DE LA MENTE 

Tomemos un trozo de papel blanco y escribamos en el centro la idea 

principal que tengamos con respecto al programa (cómo será, cómo 


41 


actuará, cómo se visualizará, qué será objeto de llamada). A continuación, 
en la forma más rápida posible, pues no hay mucho tiempo para pensar 
concienzudamente sobre ello, tome nota de una idea, una frase o una 
palabra que parezca tener relación con esa idea principal. Enlace las dos 
con una línea. Piense en otra idea que tenga relación con una de las dos 
anteriores que ya tiene en la página, escríbala y trace una línea de enlace. 
Ahora escriba otra idea relacionada con una de las anteriores. 

Continúe de esta manera, pensando nuevas ideas relacionadas con una 
o más de las que ya tiene en la página y escribiéndola en esta última. 
Luego, dibuje todos los enlaces principales con las ideas ya reflejadas en el 
papel. No haga ninguna pausa para evaluar ninguna de las ideas. 
Simplemente ha de limitarse a anotarlas, de la forma más rápidamente 
posible y trazar los enlaces correspondientes. Siga este procedimiento 
hasta que haya desarrollado todas las ideas posibles. Debe acabar por 
obtener algo similar a lo que se representa en la Figura 3.8. En esta figura 
se representa la idea central con la que comencé lo que luego sería el 
programa de “Minas de Merlín”. 

Este es un mapa de mente. Consiste en una planificación de las ideas 
que tiene acerca de su programa o de su juego, enlazadas en las formas 
que hace que tenga más sentido para usted al nivel intuitivo. Ahora tome 
todas las notas, listas, bosquejos y apuntes que haya hecho sobre el juego 
y si no se hubieran incorporado al mapa de la mente, añádalas y sus 
enlaces en el lugar más lógico. 

Encontrará que algunas ideas tienen muchas ramificaciones, mientras 
que otras solamente tienen una o dos. Aquellas que tienen muchas 
ramificaciones son las ideas principales que, por consiguiente, se harán las 
rutinas principales en su programa; aquellas que sólo tengan unas pocas 
ramificaciones serán módulos pequeños con menor utilización y aquellas 
que tengan solamente una ramificación no necesitarán ser módulos 
separados pero se podrán incluir en la idea más amplia de la que sean 
ramificación: por ejemplo, en la Figura 3.8, la rutina de “arma” y la 
rutina de “retirada” se pueden incluir en la rutina de ““combate””, pero la 
rutina de ““muerte” no lo será, pues se puede llamar por parte de otra 
rutina. 


EL DIAGRAMA DE FLUJO PRINCIPAL 


Un mapa de la mente cristaliza la totalidad de nuestras ideas y clarifica las 
relaciones existentes entre ellas, de modo que podamos ver qué separacio- 
nes existen y si es sensible la lógica. Sin embargo, no se trata de una 
descripción exacta de un programa en modo alguno. La mejor forma de 
conseguirlo es probablemente construyendo un diagrama de flujo o 
algoritmo. Este es un modelo mucho más preciso, pero es más difícil de 
construir, sobre todo si todavía no tenemos una idea clara sobre algunos 
aspectos del programa. Por ello resulta conveniente construir primero un 
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ALIMENTO. ———_—_—_—_—_—_—_—_—_——- VENENO 


INSTRUCCIONES MAPA POCIONES 


MINAS DE MERLIN ELEMENTOS 
MAGICOS 
PELIGROS 
POZOS MONSTRUOS 
MUERTE COMBATE 
Figura 3.8 RETIRADA ARMAS 


mapa de la mente para generar las ideas, como una forma de hacer el 
trabajo de cimentación y luego, plasmarlo en un diagrama de flujo para 
hacer las relaciones sin ambigiúedad. No podrá codificar fácilmente un 
programa a partir de un mapa de la mente, pero si podrá hacerlo a partir 
de un diagrama de flujo bien construido. 

A lo largo de este libro hay varios ejemplos de diagramas de flujo. 
Algunos son bastante precisos, siendo bastante próximos a una rutina en 
BASIC real; otros son de carácter muy general, dejando algunas etapas 
implícitas o sin desarrollar. Es esta última clase la que debe abordar 
primero en la planificación de su juego, dando una amplia descripción de 
todo lo que ocurrirá en el programa, con alguna indicación del orden en 
que se producirán. Con el empleo del mapa de la Figura 3.8, podríamos 
construir un diagrama de flujo como el que se representa en la Figura 3.9. 


43 


Una vez que hayamos elaborado el diagrama de flujo principal, 
podemos considerar sucesivamente cada uno de los bloques, tratándolo 
como un módulo independiente y dibujando un diagrama de flujo para 
todos los procesos implicados en el mismo (posiblemente, elaborando otro 
mapa particular para esa sección). Cada uno de estos procesos debe tener, 
si fuera necesario su propio diagrama de flujo. Continuaremos de esta 
manera hasta que nuestro diagrama de flujo comience a leerse como un 
programa y estemos en condiciones de codificar nuestro módulo. Hay que 
asignar número de línea a cada uno de los bloques en los borradores más 
especificos y a continuación, podremos comenzar a traducir las etapas del 
diagrama de flujo en las líneas correspondiente del código BASIC. 


. IMPRIMIR INSTRUCCIONES 

. VISUALIZAR SALIDAS 

. DESPLAZAR PROTAGONISTA 

. SI EL PROTAGONISTA ENCUENTRA A UN MONSTRUO EN- 
TONCES PASAR A 6 

5. SI EL PROTAGONISTA CAE EN UN POZO ENTONCES PASAR 

A9 

6. CALCULAR COMBATE 

7. SI EL PROTAGONISTA ESTA MUERTO ENTONCES PASAR A 
10 DE OTRO MODO PASAR A 2 

. VISUALIZAR LA SALIDA DEL POZO 

. CALCULAR EL EFECTO DE LA CAIDA 

. SIEL JUGADOR ESTA MUERTO ENTONCES FINALIZAR EL 
JUEGO, DE CUALQUIER OTRO MODO PASAR A 2 


Figura 3.9 


Hui — 


oOvwo 


Hemos de examinar detenidamente el módulo de “instrucciones” de la 
Figura 3.9 a título de ejemplo. En primer lugar, decidimos que habrá 
instrucciones escritas visualizadas antes de que comience el juego. A 
continuación, dibujamos un diagrama de flujo como el de la Figura 3.9, 
poniendo el bloque de instrucciones en el lugar correcto. Tomando una 
hoja de papel aparte, trazamos un diagrama de flujo del módulo de 
instrucciones, quizás como el que se representa en la Figura 3.10. 


1|. PARPADEO DEL TITULO DEL JUEGO DIEZ VECES 

2. IMPRESION DE LA DESCRIPCION DEL JUEGO 

3. DESCRIPCION DE LAS ACCIONES POSIBLES DEL JUGADOR Y 
DE LAS TECLAS DE CONTROL DISPONIBLES. 

4. EL JUGADOR HA DE PULSAR “S” PARA INICIAR EL JUEGO 


Figura 3.10 
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Cada una de las partes de la Figura 3.10 necesita una elaboración 
adicional. La instrucción podría ser elaborada de nuevo como se muestra 
en la Figura 3.11. 


. AÑADIR 1 AL CONTADO 

. BORRAR PANTALLA 

. IMPRIMIR TITULO DEL JUEGO 

. SIEL CONTADOR <> 10 ENTONCES PASAR A 1 

. BORRAR LA PANTALLA 

. PASAR A LA SIGUIENTE SECCION DEL PROGRAMA 


Figura 3.11 


Dn E Yon — 


Lo anterior tiene un aspecto muy similar a un programa en BASIC. 
Solamente es un pequeño paso desde la Figura 3.11 a una sección de 
código similar al que se muestra en la Figura 3.12. 


10 FOR I = 1 TO 10 

20 CLS 

30 PRINT “Las Minas de Merlín” 
40 NEXT I 

50 CLS 


Figura 3.12 


Aunque este elemento de programación sea elemental, el mismo 
procedimiento debe utilizarse para tareas más complejas. De hecho, es 
más importante utilizarlo para tareas complejas porque sin su empleo 
podemos olvidar etapas cruciales de la codificación cuando se vaya a 
escribir realmente el programa. La utilización de una serie de diagramas 
de flujo como este puede parecer aburrido, pero los juegos de aventuras 
son programas muy largos y por ello, son propensos a muchas clases 
diferentes de ““gazapos” o errores de programación. El tiempo que 
podamos perder en la etapa de planificación se compensará ampliamente 
cuando veamos que no tenemos que realizar casi ninguna depuración. 

Sin embargo, este procedimiento no puede asegurar, por sí mismo, un 
diseño perfecto, exento de errores. Habrán de tomarse otras medidas. Una 
cosa importante que se tiene que hacer es cerciorarse de que el programa 
está ampliamente documentado. No hay que tirar ninguna nota de diseño 
y hay que cerciorarse de que todos los pensamientos y los cambios 
concebidos se han escrito en el momento oportuno de modo que no se 
puedan perder y ha de mantenerse el programa provisto de todas las 
sentencias REM necesarias. Una buena idea es utilizar incrementos de 10 
líneas al escribir sus programas en BASIC y colocar todas las sentencias 
REM en líneas que finalicen con un 9. De esta forma, cada sección de 
código tendrá su identificador inmediatamente antes de ella y sabrá qué 
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líneas buscar cuando examine su programa durante el desarrollo en 
búsqueda de una sección fundamental. A continuación, cuando se haya 
concluido el programa, si desea borrarlas (para ahorrar memoria o para 
hacer el listado opaco para un usuario), será una tarea sencilla avanzar a 
través del programa y borrar todas las líneas que finalicen en 9. 


3.6 Plan de ejemplo 


La mayor parte de los principios tratados en este libro se ilustrarán a 
través de los juegos de aventuras de muestra que se listan en los capítulos 
5 y 6, que se podrán obtener también en una casete aparte. Concluyamos 
este capítulo indicando cómo concebir uno de estos programas y las 
etapas de diseño que seguir antes de que iniciara la codificación. 

En primer lugar, decidir qué deseaba mostrar tantos aspectos de la 
programación de un juego de enigmas como fuera posible, pero de una 
forma que no fuese demasiado compleja de entender. En consecuencia, era 
mi deseo conseguir un juego razonablemente convencional, y para ello me 
decidí por una narración basada en el viaje de un caballero a Camelot. 
Opté por que las partes fueran moduladas de modo que otros programa- 
dores pudieran utilizarlas si ese era su deseo y pretendí que existiera 
alguna variedad de entrada, salida y decisiones del jugador, así como el 
texto habitual. 

Habida cuenta de la necesidad de hacer que los principios fueran claros 
para cualquier principiante, consideré, en un principio, que esta especifica- 
ción para un programa era realmente demasiado complicada y que se 
podría hacer mejor mediante dos programas en lugar de uno: uno que 
fuera básicamente un juego de enigmas y el otro un juego de combate, 
siendo esta la razón de que las dos aventuras incluidas en este libro sean 
tan diferentes en su enfoque. 

En este punto, me dispuse a elaborar varios mapas de la mente, uno 
sobre todos los aspectos de los juegos que deseaba ilustrar, otro sobre todo 
lo que conocía acerca de Camelot y de los Caballeros, otros sobre los 
demás elementos narrativos posibles y otro sobre las características del 
juego que deseaba incluir. Como consecuencia de todo esto, elaboré mi 
primer diagrama de flujo principal, que se muestra en la Figura 3.13. 


Instrucciones. 

Visualización de mapa. 

. Impresión de la descripción. 

Introducción de las órdenes. 

Cálculo del efecto. 

. Si el jugador no ha ganado o ha perdido entonces pasar a la etapa 2. 


Figura 3.13 


DMA 
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En este otro punto, tuve que hacer también algunas notas sobre la 
clase de enigma que podría aplicar y un bosquejo de una visualización en 
pantalla simple. 

Ahora solamente podría pensar acerca de la codificación pero no 
podría llegar más allá en cuanto a la escritura de cualquier parte del 
programa. Escribí una lista de todas las rutinas y módulos que se 
necesitarían y asigné un bloque grande de números de línea a cada uno, 
intentando sobreestimar más bien que subestimar el número de líneas que 
sería necesario. 

Cuando se realiza esta tarea es mejor tener presente que cuando se 
busca una subrutina, la mayoría de las máquinas, incluyendo el Spectrum, 
realiza una búsqueda a través de todas las líneas que comienzan con el 
número más bajo hasta que se encuentra la rutina correcta. Por consi- 
guiente es preferible poner los bloques más frecuentemente utilizados a 
principio del programa y los bloques que se emplean con menos frecuencia 
hacia el final. 

Normalmente, las rutinas para el movimiento y la visualización en la 
pantalla irían al principio porque se utilizan en casi todo turno de 
ejecución, pero las instrucciones y rutinas de inicialización, que solamente 
se utilizan una vez en el juego, iría al final. Aunque ello parezca algo 
ilógico, puede hacer que la ejecución del programa se realice con mucha 
mayor rapidez. Sin embargo, si queremos una ejecución mucho más 
rápida necesitaremos utilizar código de máquina o un compilador (que 
transforma el BASIC en código de máquina), pero estos procedimientos 
quedan fuera del objeto de este libro. 

En esta etapa, el diseño del programa para el juego del trono de 
Camelot estaba en la forma que se indica en la Figura 3.14, aunque, como 
se verá más adelante, el programa final difiere algo del diseño inicial. Las 
instrucciones, la rutina de inicialización y las sentencias DATA, que se 
suelen utilizar solamente una vez, están al final, mientras que las rutinas 
que se emplean con mayor frecuencia están al principio. 

El programa principal, líneas O a 999, no es realmente otra cosa sino 
una parte de la inicialización (que coloqué aquí para facilitar su hallazgo 
durante el desarrollo del programa), con tres llamadas a subrutinas que, a 
su vez, imprimirán las instrucciones, completarán la inicialización e 
imprimirán la primera visualización, y cinco líneas de bucle que harán lo 
siguiente: primero se realiza una comprobación para ver si el juego está 
concluido, luego se llama el bloque de entrada y si esta última es correcta 
será objeto de llamada el bloque verbal adecuado; a continuación, el 
bloque verbal llamará al bloque de movimiento, que, a su vez, actualizará 
la visualización del mapa y de la descripción verbal o llamará a una o más 
de las rutinas a partir de los bloques de las descripciones de los objetos y 
de las posiciones; si con ello no se finaliza el juego (estableciendo una 
variable denominada “muerte” a algún valor que no sea cero), entonces se 
repetirá el bucle. 
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BLOQUE 1  0-999 PROGRAMA PRINCIPAL 

BLOQUE 2 1000-1999 PROCESO ORDENES DE ENTRADA 

BLOQUE 3 2000-2999 DESPLAZAR JUGADOR, IMPRIMIR MAPA 
E IMPRIMIR DESCRIPCION 

BLOQUE 4 3000-3999 RUTINAS VERBALES 

BLOQUE 5 5000-5999 DESCRIPCIONES OBJETOS 

BLOQUE 6 6000-6999 DESCRIPCIONES POSICIONES 

BLOQUE 7 8000-8999 PREPARACION E INICIALIZACION 

BLOQUE 8 8500-8999 INSTRUCCIONES 

BLOQUE 9 9000-9499 SENTENCIAS DE DATOS 

BLOQUE 10 9900-9999 FINAL RUTINA 


Figura 3.14 


El diagrama de bloques representa el diagrama de flujo de control que 
elaboré (Figura 3.15). El motivo de que existan algunas separaciones en 
los números en el diagrama de bloques se debe simplemente a que dejé un 
espacio para cualquier adición posterior que considerara oportuno des- 
pués del diseño principal. En este caso, no hubo ninguna adición, pero se 
dejó un espacio lógico para cualquier modificación que el lector deseara 
introducir en este programa. En la Figura 3.14 se muestra la naturaleza 
modular de un programa similar a éste y en la Figura 3.15 se ilustra cómo 
dicha aventura está casi completamente basada en la prueba IF... THEN 
(Si... ENTONCES). 


3.7 Temas sugeridos para aventuras 
FANTASÍA 


1. Un mundo submarino (Atlántida, Mu, Capitán Nemo) 

2. Un mundo completamente invernal 

3. Un mundo en el firmamento, poblado por criaturas provistas de alas 

4. Un mundo en el interior de un organismo viviente (como el Viaje 
Fantástico) o una máquina (como Tron) 

5. El jugador ha de aprender las facultades mágicas de una raza perdida, 
no a través de un combate, sino interpretando correctamente una serie 
de pistas mágicas 

6. Un juego basado en una serie de maginas o religiones en competencia, 
en donde símbolos similares tengan significados diferentes (por consi- 
guiente, pistas ambiguas) 

7. El jugador diseña y actúa como un monstruo de alguna especie, tal 
como un dragón o un vampiro 

8. Un juego basado en alguna característica geográfica inusitada, tal como 
el interior de un volcán, sobre una serie de islas flotantes, en el interior 
de un glaciar, entre las copas de los árboles o completamente en la cara 
de un acantilado 
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18. 


. INTRODUCCION DE NUEVA ORDEN 
. SI LA ORDEN ES DE MOVIMIENTO ENTONCES PASAR AL 


NUMERO 7 


. SILA ORDEN SE REFIERE A UN OBJETO ENTONCES PASAR 


AL NUMERO 12 


. SI LA ORDEN ES “HELP” (AYUDA) ENTONCES IMPRIMIR 


UNA PISTA Y PASAR AL NUMERO 1 


. SILA ORDEN ES “INVENTARIO” ENTONCES IMPRIMIR EL 


INVENTARIO Y PASAR AL NUMERO 1 


. SILA ORDEN NO ES NINGUNA DE LAS ANTERIORES EN- 


TONCES IMPRIMIR “NO COMPRENDO” Y PASAR AL NUME- 
RO 1 


. SIEL MOVIMIENTO PREVISTO ES IMPOSIBLE DE REALIZAR 


ENTONCES IMPRIMIR “ERROR” Y PASAR AL NUMERO 1l, 
DE CUALQUIER OTRO MODO, PASAR AL NUMERO 8 


. DESPLAZAR EL PROTAGONISTA 

. IMPRIMIR LA NUEVA VISUALIZACION 

. ACTUALIZAR LOS VALORES DE TODAS LAS VARIABLES 

. PASAR AL NUMERO 1 

. SI LA ORDEN NO ES POSIBLE ENTONCES IMPRIMIR “NO 


PUEDO HACER ESO” Y PASAR AL NUMERO 1, DE CUAL- 
QUIER OTRO MODO, PASAR AL NUMERO 13 


. CALCULAR EL RESULTADO DE LA ORDEN 
. IMPRIMIR EL RESULTADO 
. ACTUALIZAR LOS VALORES DE TODAS LAS VARIABLES 


CORRESPONDIENTES 


. SI EL JUEGO ESTA CONCLUIDO ENTONCES PASAR AL 


NUMERO 17, DE CUALQUIER OTRO MODO, PASAR AL NU- 
MERO 1 


. SIEL JUGADOR HA GANADO, ENTONCES IMPRIMIR “BIEN 


HECHO”, DE CUALQUIER OTRO MODO, IMPRIMIR “MALA 
SUERTE” 
FINALIZAR EL JUEGO 


Figura 3.15 


CIENCIA FICCIÓN 


1. 


Un planeta con una topología o forma no habitual, no esférica, tal 
como un mundo que realmente sea plano o un juego basado en el 
mundo anular de Larry Niven 


. Un juego en el que el jugador desempeñe el papel de un robot 
. Un juego en el que el jugador sea una máquina, tal como la computa- 


dora en una nave galáctica, la propia nave galáctica o un vehículo 
exploratorio en un nuevo planeta 
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. El jugador elige una raza de invasores para desempeñar dicho papel y 


debe comportarse dentro de las limitaciones de esa raza (v.g., un 
insecto gigante o una planta inteligente) 


. Un juego basado en el desplazamiento en el tiempo, en el que los 


jugadores deben recoger pistas a partir de ambientes diferentes 


. Evitar que el científico malvado conquiste la tierra 


TEMAS HISTÓRICOS 


Í.. 


Un juego basado en una civilización remota o exótica, tal como las de 
China, Japón, Tibet, las Islas del Pacífico o sobre los Incas o los 
Aztecas 

Un juego basado en un acontecimiento o periodo histórico particular, 
tal como el esplendor o la decadencia de Roma, el descubrimiento de 
América, la conquista de Asia por Alejandro Magno, las guerras entre 
los Mongoles y los Chinos o la difusión del Islam 


. Un acontecimiento o competición de carácter deportivo utilizado como 


tema básico, tal como una carrera de yates alrededor del mundo, una 
temporada de cricket, un Grand Prix 

Simulaciones del mundo real, tal como un juego sobre la industria de 
las grabaciones, o la publicidad o el cine 


. Espías, espionaje y terrorismo 
. Un juego ecológico en el que el jugador debe desempeñar un papel 


biológico diferente 


PLANIFICACION DE LA 
Á PRESENTACION VISUAL 


Un aspecto crucial de la mayoría de los juegos, pero sobre todo de los 
juegos de computadoras, es la apariencia fisica del juego; es decir, lo que 
aparece en la pantalla. Ello significa que se debe dedicar una gran parte 
del esfuerzo de diseño a la visualización del juego. ¿Qué verá realmente el 
jugador? En un juego de gráficos, la respuesta a esta pregunta puede 
controlar casi todos los aspectos del juego y un juego de aventuras puede 
ser el mismo si, por ejemplo, es primariamente un laberinto a resolver o 
un juego en tiempo real. Sin embargo, en la mayor parte de los juegos de 
aventuras, no se puede permitir que la visualización sea el aspecto más 
importante, puesto que se le debe dar más relevancia a la estructura del 
juego. No obstante, necesitará visualizar texto y probablemente también 
elementos gráficos, por lo que debe tomar una decisión sobre cómo se 
mostrarán y sobre cómo encajarán entre sí. 


4.1 Estrategias y menús 


Las interrogantes (preliminares a responder son las siguientes: 


l. ¿Es la visualización simplemente texto, simplemente gráficos o una 
mezcla de ambas cosas? 

2. ¿Habrá alguna interacción en tiempo real y, si la hubiere, cuál será el 
intervalo de tiempo para visualizar información en la pantalla? 

3. ¿Hemos de utilizar alguna de las características especiales de la 
máquina? Para el Spectrum, ello significa decidir sobre si necesitamos 
utilizar algunas de las características siguientes: 

colores parpadeantes 
gráficos de alta resolución 
utilización de la pantalla separada de dos líneas 
color 
gráficos definidos por el usuario. 
4. ¿Cuánta información se mostrará a la vez? 


Existen dos estrategias de visualización. La primera consiste en añadir, 
de forma sucesiva, líneas a la visualización de modo que se desplace de 
forma continua a través de la pantalla en sentido ascendente. Este es el 
método más fácil, pero uno de los menos atractivos y de peor apariencia. 
Llena la pantalla con una gran cantidad de información que dificulta la 
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localización del elemento exacto que se desea y la mayor parte de esa 
información no se desea en ningún punto particular en cualquiera de los 
juegos. Cada vez que se desplaza hacia arriba la visualización completa de 
una forma poco atractiva y, en el Spectrum, la necesidad de responder a la 
pregunta “Scroll?” añade una complejidad innecesaria y produce un 
retardo en el juego. 

Un método algo más atractivo y cómodo es borrar la pantalla a 
intervalos periódicos. Ello puede hacerse cada vez que se llena la pantalla, 
lo que elimina la necesidad de un desplazamiento ascendente continuado, 
pero es preferible que se haga después de que se muestre cada bloque de 
información. La información visualizada se divide en clases separadas, 
cada una de las cuales tiene su propia subrutina o su propio procedimiento 
y luego, cada una de estas clases es objeto de llamada cuando se requiera. 
Para hacerlo así normalmente utilizaríamos lo que se denomina un 
método controlado por menú. Hablando en términos generales, un menú 
es un conjunto de opciones visualizadas en la pantalla, a partir del cual el 
usuario efectúa su selección. Introducirá su selección y será objeto de 
llamada la subrutina correspondiente borrando el menú de la pantalla y 
visualizando la información adecuada a esa subrutina. Por ejemplo, el 
menú principal podría ser como sigue: 


Opción Selección 
Combate 1 
Reaprovisionamiento 2 
Estado 3 


Si el usuario desea la rutina de combate tecleará **1” y la visualización en 
la pantalla cambiará a la correspondiente a esa rutina de combate. Por 
ejemplo, podría mostrar una visualización gráfica de lo que ve una 
computadora de combate de una nave espacial. Al teclear “2”, podría 
obtenerse una visualización de gráficos diferente, por ejemplo, un juego de 
gráficos en tiempo real en el que dos naves espaciales mostradas en la 
pantalla han de ensamblarse para reaprovisionamiento o repostaje. 

Es bastante posible que al realizar una selección en un menú nos pueda 
llevar a la visualización de otro menú, que represente, en efecto, una serie 
de subrutinas anidadas. Por consiguiente, al seleccionar la opción 3 
anterior podría conseguirse la visualización siguiente: 


Opción Selección 
Combustible 1 
Munición 2 
Daños de batalla 3 


La selección de una de estas opciones podría conducirnos a un nuevo 
menú y así sucesivamente, hasta que se alcance el límite de anidamiento de 
la microcomputadora. Una serie de dichos menús es una forma de guiar a 
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un usuario a través de la estructura compleja de un programa hasta la 
rutina real requerida. Se utiliza sobre todo en los programas comerciales y 
resulta improbable que usted genere un juego tan complejo como dicho 
software comercial. Sin embargo, es una forma útil de relacionar entre sí 
las visualizaciones. Cuando el usuario haya encontrado su camino hacia la 
rutina que desea y haya realizado la tarea que requiere “navegando” a 
través de una serie de pantallas de información (cada una de las cuales 
borra la pantalla anterior), la pantalla volverá a borrarse y retornará al 
menú original. Este menú se suele denominar el ““menú principal”. 

La utilización del método de desplazamiento vertical (*““scrolling””) no 
precisa ninguna planificación ni ninguna programación en absoluto 
puesto que el método habitual de la mayor parte de las microcomputado- 
ras es visualizar cada línea de información a la vez y desplazar en sentido 
ascendente dicha información cuando la pantalla está llena. Para borrar la 
pantalla en los momentos adecuados, utilizando, o no, un sistema 
controlado por menú, exige una programación concienzuda. Suele existir 
una orden de BASIC para borrar la pantalla, a menudo de la forma 
utilizada por el Spectrum CLS. Para la mayoría de los fines, sólo 
necesitamos dividir toda la salida en bloques adecuados, colocar cada 
bloque en una subrutina y ejecutar la primera orden de cada subrutina 
CES. Sin embargo, en algunos casos, pudiera ser que no quisiéramos 
colocar la salida en una subrutina; por ejemplo, en las instrucciones al 
comienzo de un juego. En este caso, tenemos que componer cada pantalla 
completa de información de modo que sea más fácil de interpretar, 
colocando una orden CLS después de cada pantalla sucesiva. En este caso, 
hay que recordar que las pantallas se borrarán demasiado rápidamente 
para que cualquiera pueda leerlas, por lo que debemos colocar un retardo 
de alguna clase al final de cada sección. 

Existen dos formas de retardo: una forma consiste en hacer que la 
computadora realice un proceso sin resultado durante un período determi- 
nado y la otra forma consiste en efectuar una retención del programa 
hasta que el usuario introduzca alguna información. El empleo de la 
primera alternativa significa que el lector tiene un período predeterminado 
en el que puede efectuar su lectura, que puede ser demasiado largo o 
demasiado corto para algunos de ellos, pero que garantiza que el resto del 
programa se llevará a cabo. La utilización de la segunda alternativa 
permite al usuario leer la información en su propio tiempo, pero implica 
que ha de tomarse alguna acción para asegurar una operación continuada. 
Por consiguiente, debe añadirse una instrucción que explique qué clase de 
entrada es la que se requiere. 

El primer tipo de retardo se puede conseguir con la simple utilización 
de un bucle repetido, que suele ser un bucle FOR...NEXT, por ejemplo: 


100 FOR I=1 TO 1000 
110 NEXT I 


El intervalo exacto que se consigue de esta forma dependerá de la 
microcomputadora utilizada, por lo que ha de descubrirse de forma 
experimental por tanteo. El Spectrum tiene la orden PAUSE y otras 
microcomputadoras tienen órdenes como INKEY que da lugar a que se 
espere durante un tiempo especificado o hasta que se pulse una tecla 
determinada. Para dichas microcomputadoras, el mejor método es, pues, 
dar instrucciones al programa para que espere durante un largo tiempo 
utilizando estas Órdenes de modo que se proporcione mucho tiempo 
incluso para el lector más lento. Sin embargo, los lectores más rápidos 
pueden interrumpir en cualquier momento dicho proceso con la simple 
pulsación de una tecla. Por consiguiente, si consideramos que llevará 10 
segundos la lectura lenta de una pantalla particular, añadiendo 5 segundos 
más para salvar cualquier contingencia y multiplicamos por 50 (el número 
de cuadros de televisión que la orden PAUSE espera por segundo), 
podemos utilizar una rutina como la siguiente: 


10 REM IMPRIMIR PRIMERO LA PANTALLA 


40 PRINT “PULSAR CUALQUIER TECLA PARA CONTINUAR” 
50 PAUSE 750 
60 REM IMPRIMIR AHORA LA SIGUIENTE PANTALLA 


Si su microcomputadora carece de dichas órdenes, tendrá que elegir 
entre el bucle repetido (anterior) o la introducción por parte del usuario. 
Habida cuenta de que la entrada no hace nada más que permitir que 
continúe el programa, no importa lo que sea dicha entrada, por lo que es 
habitual permitir que se pulse cualquier tecla. Una línea tal como: 


100 GET AS: IF AS$=“” THEN GOTO 100 


será admisible en la mayor parte de los dialectos de BASIC. La primera 
parte de la línea busca el carácter de entrada, mientras que la segunda 
parte retorna a la primera si no se ha introducido ninguno; haciendo que 
el bucle continúe indefinidamente hasta que se haya introducido por el 
teclado un carácter. 

Resulta posible escribir una pequeña rutina en la mayor parte de los 
dialectos de BASIC para realizar la misma función que la de PAUSE del 
Spectrum, tal como: 


100 FOR I=1 TO 1000 

110 GET AS 

120 IF AS<>*” THEN I=999 
130 NEXT I 


Sin embargo, diferentes microcomputadoras utilizan diferentes formas de 
GET, GETS, INKEY e INKEYS$, por lo que debe cerciorarse de que 
comprende a fondo los subterfugios de su propio sistema. 
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4.2 Una mirada por las ventanas 


Un mejor método que el del borrado de la pantalla, de forma continuada 
o periódica, es el empleo de las “ventanas” de pantalla. Una ventana 
puede considerarse como una sección de la pantalla definida para un tipo 
de visualización particular. Por ejemplo, la microcomputadora BBC le 
permite definir ventanas separadas de texto y de gráficos, utilizando partes 
independientes de la pantalla de la unidad de presentación visual (VDU). 
En la ventana de texto, solamente aparecerá texto mientras que la ventana 
de gráficos solamente aparecerá gráficos y texto tratado como gráficos. 
Estas ventanas pueden ser cualquier parte rectangular de la pantalla. 

Sin embargo, dicha capacidad no es de dotación normal, por lo que, 
normalmente, tendríamos que escribir nuestras propias rutinas de softwa- 
re para crear dichas “ventanas”. En el caso del Spectrum, dos ventanas 
están ya definidas. Las 22 líneas superiores constituyen una ventana y las 2 
líneas inferiores constituyen otra. Desde el punto de vista del BASIC, la 
ventana inferior sólo se puede utilizar habitualmente en las sentencias 
INPUT, lo que limita bastante su utilidad. Como una sentencia INPUT 
es, en muchas formas, análoga a una sentencia PRINT en Spectrum 
BASIC, podemos utilizar la ventana inferior para visualizar texto. Por 
ejemplo, podríamos escribir una rutina de “pulsar cualquier tecla” que 
imprimiera una sentencia en la ventana inferior, eligiéndose la sentencia 
real según las circunstancias. 

Supongamos que tuviéramos tres tipos de consejos en nuestro juego, 
presentados como tres cadenas, por ejemplo: 


10 LET A$ = “Yo no haría eso si yo fuera usted” 
20 LET B$ = “No puede hacer eso” 
30 LET CS = “Necesita más fuerza” 


Por consiguiente, tendríamos rutinas en cualquier otro lugar del programa 
que elegirían la advertencia adecuada, dependiendo de las circunstancias. 
El resultado de la rutina sería asignar a la cadena de advertencia W$, una 
de estas advertencias elegidas, con una sentencia como la siguiente: 


200 IF A=2 THEN LET WS$=BS 


Ello podría leerse como: Si las circunstancias son tales que el jugador no 
puede hacer lo que desea, entonces la advertencia será “no puede hacer 
eso”. Para imprimir la advertencia elegida en la ventana inferior, efectua- 
ríamos la llamada de nuestra subrutina INPUT especial que sería como la 
siguiente: 


500 INPUT (WS); AT 2,0; “Presionar cualquier tecla para continuar”; 


Z5 
510 RETURN 


3.-Williams 


Dicho de otro modo, podemos utilizar la misma subrutina para imprimir 
cualquier sentencia que deseemos en la ventana inferior, con tal de que 
dicha sentencia se haya asignado a WS. 

Ello nos da una sugerencia sobre cómo podemos generar ventanas en 
otras partes de la pantalla. Podemos escribir subrutinas que impriman 
variables en algunas posiciones de la pantalla y asignar a estas variables 
los valores reales o las cadenas que queramos imprimir. Esta solución es, 
en muchos aspectos, más elegante y de mayor utilidad que la de haber 
insertado las coordenadas AT o TAB en cada sentencia PRINT, porque 
solamente tenemos que calcular las coordenadas necesarias una vez para 
cada ventana y luego, retenerlas en la subrutina. Sin embargo, si así lo 
prefiere, puede definir ventanas de texto de modo que cada clase de 
sentencia PRINT deba estar en un lugar particular en la pantalla y por 
consiguiente, deba tener las coordenadas AT o TAB correspondientes. 

Ello se puede demostrar con facilidad. Supongamos que deseamos dos 
ventanas pequeñas para texto, una que visualice la fortaleza actual y el 
poder mágico del protagonista del jugador y la otra que contenga una lista 
de las cosas que podría ver. En el primer caso, probablemente sería dos 
variables numéricas que se actualizarían a intervalos periódicos. De este 
modo, la rutina de actualización puede ser también la rutina de impresión, 
como sigue: 


100 REM HACER PRIMERO LOS CALCULOS 


140 PRINT AT 1,30; FORTALEZA 
150 PRINT AT 2,30; PODER 


Esta rutina actúa de forma adecuada. A medida que las variables 
FORTALEZA y PODER cambian a través del juego, se actualizarán y se 
imprimirán inmediatamente sobre los valores antiguos. 

Para nuestra segunda clase de salida, una lista de elementos de datos, 
esta rutina no podría trabajar tan bien. Es presumible que en el juego 
completo habrá un gran número de cosas que verse, pero el protagonista 
no será capaz de ver todas ellas al mismo tiempo. Ello implica que la lista 
variará de una situación a otra. En ocasiones, no habrá ningún objeto y, a 
veces, habrá muchos. En consecuencia, las técnicas de sobreimpresión de 
una posición exacta no actuarán adecuadamente, sobre todo cuando las 
cadenas tiendan a ser de longitudes diferentes. Lo que se necesita es una 
rutina que no sólo llene tanta parte de la ventana predeterminada como se 
necesite con el texto en curso, sino que también borre la totalidad del resto 
de la ventana en caso de que el anterior texto objeto de impresión en esa 
zona ocupara más espacio. 

Supongamos que ninguna lista de elementos de datos ocupará más de 
tres líneas de la pantalla. Por consiguiente, necesitaremos una ventana de 
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tres líneas, una rutina para borrar esa ventana, una rutina para poner 
junto el texto real a partir del conjunto de cadenas posibles y una rutina 
para imprimir (PRINT) el texto elegido en la ventana correcta. Utilicemos 
las tres últimas líneas de la pantalla del Spectrum (líneas 19, 20 y 21) y 
supongamos que los elementos de datos están listados como elementos en 
la matriz Z$(10). A partir del conjunto de variables posibles, el programa 
ha seleccionado X$(3), X$(5) y X$(8) que son “un acotillo”, “una piña” y 
“un collar verde y oro” respectivamente. Esta lista irá precedida por la 
frase: “Usted ve:”. 

En primer lugar, obtenemos una lista de elementos de datos utilizando 
el concatenador de cadenas (el signo más) para transformar nuestras 
cadenas separadas en una sola cadena, añadiendo los elementos elegidos a 
la frase de “Usted ve:”. La rutina ha de saber cuántos elementos ha de 
buscarse y cuáles son, por lo que las rutinas buscadoras compilarán una 
cadena (L$) constituida por los números de los elementos seleccionados en 
la matriz X$: En este caso L$ será “358”. La longitud de la cadena L$ 
indica a la rutina de visualización cuántos elementos hay que buscar y 
añadir, así como los números de los elementos reales. Ello se hace por 
medio de las líneas 600 a 640. A continuación, la línea 650 borra la 
ventana seleccionada imprimiendo tres líneas en blanco. Finalmente, la 
línea 660 imprime la nueva cadena en la posición correcta: 


600 REM PARA IMPRIMIR UNA COLECCION DE CADENAS 
EN UNA POSICION PARTICULAR 

610 LET P$=“Usted ve:” 

620 FOR I=1 TO LEN(L$) 

630 LET P$= PS + XS(VAL(LS()) 

640 NEXT I 

650 PRINT AT 19,0,...., 

660 PRINT AT 19,0;PS 


El mismo procedimiento se puede utilizar cualquiera que sea el número 
de líneas de pantalla o el número de elementos en la lista. Basta cambiar el 
número de comas en la línea 650 y el número de PRINT AT. Sin embargo, 
supongamos que deseemos una ventana en el lado izquierdo de la pantalla 
en lugar de en la parte superior o en la parte inferior y una ventana que 
sólo tenga una anchura de 8 caracteres. Tendremos que imprimir (PRINT) 
solamente 8 espacios en blanco, sin líneas completas y cada cadena 
sucesiva de 8 caracteres debe estar separada. No se puede imprimir como 
una Cadena continua ni se recurrirá por escritura una parte de la pantalla 
fuera de la ventana deseada. 

En este caso, tendremos que utilizar variables como especificadores de 
la posición de PRINT, de modo que la posición vertical se pueda 
incrementar para cada nuevo elemento de PRINT. Volvamos a escribir las 
lineas 600 a 670 para obtener una ventana de 8 caracteres por 6 líneas 
(máximo) en el lado izquierdo de la pantalla, comenzando 5 líneas abajo: 
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600 REM PARA IMPRIMIR UNA COLECCION DE CADENAS 
EN UNA COLUMNA DE 8x6 A LA IZQUIERDA 

620 FOR I= 1 TO 6 

630 PRINT AT 4+1, 0; ”:REM 8 ESPACIOS 

640 NEXT 1 

650 FOR I = 1 TO LEN(LS) 

660 PRINT AT 4+1, 0:XS(VAL(LS()) 

670 NEXT 1 


De estos dos ejemplos podrá deducir cómo se pueden definir ventanas de 
texto en casi cualquier lugar de la pantalla. Cada posición de PRINT 
separada es, en sí misma, una ventana de texto, por lo que el número 
máximo de ventanas sería el número de estas posiciones (22 x 32 = 704). 
Aunque, en raras ocasiones, deseará más de dos o tres. El punto clave es 
decidir, lo antes posible, cuántas ventanas requerirá y de qué tamaño. Es 
conveniente escribir las subrutinas de impresión antes de que haya tomado 
una decisión sobre todo el texto que ha de visualizar, pero ello debe 
hacerse después de que haya clasificado los tipos de texto que mostrará. 
También tiene sentido en la etapa de planificación dibujar un bosquejo de 
las ventanas realizando una visualización de pantalla completa de modo 
que pueda hacerse una idea de cuán confusa u organizada aparecerá la 
pantalla para un usuario. 

Hay tres ventajas principales con el empleo de las ventanas de texto. 
En primer lugar, se consigue una visualización clara y atractiva que resulta 
agradable a la vista, bien organizada y fácil de comprender. En segundo 
lugar, se simplifica el proceso de tomar una decisión sobre qué imprimir, 
en dónde y cuándo. Y, en tercer lugar, con el empleo de las ventanas de 
texto se puede visualizar una gran cantidad de información en la pantalla 
de una sola vez y sin que se produzca ningún caos. Varias clases de 
información se pueden visualizar, de forma simultánea, sin la necesidad de 
efectuar un desplazamiento hacia arriba de la pantalla (“scrolling”), 
menús o un borrado constante de la pantalla. Por supuesto, también 
puede utilizar una sola ventana para varios fines, como si se tratara de una 
minipantalla. Si desea hacer esto último, y la rutina de limpieza de la 
ventana es compleja, suele ser preferible que tenerle como una subrutina 
separada de la rutina de impresión, pero siendo objeto de llamada por esta 
última. De esta forma, varios tipos diferentes de texto pueden utilizar la 
misma rutina de limpieza y la misma ventana sin tener necesidad de 
duplicar el código. 

Las ventanas de gráficos en la mayor parte de las máquinas se pueden 
definir de una forma similar utilizando coordenadas de gráficos, que se 
llaman las posiciones de PLOT en la mayoría de los sistemas. El Spectrum 
tiene una ventaja sobre otros varios sistemas porque sus pantallas de texto 
y de gráficos son idénticas. De este modo, el método utilizado para crear 
ventanas de gráficos puede ser idéntico al utilizado para crear texto. Las 
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únicas diferencias cruciales son que las ventanas de gráficos se definirán 
utilizando PLOT y DRAW en lugar de PRINT AT y que el punto de 
referencia, u origen, es la esquina superior izquierda para el texto y la 
esquina inferior izquierda para los gráficos. 

Supongamos que deseamos tener dos ventanas de gráficos. La primera 
constituida por un cuadrado de 8 posiciones de caracteres, comenzando en 
la esquina inferior izquierda, mientras que la segunda sea una ventana de 
10x 4 en la parte superior derecha. Teniendo presente que cacácter es una 
matriz de 8x8 de elementos de imagen, o “pixels” (ver Capítulo 17 del 
manual del Spectrum), ello nos da una ventana de 64x 64 pixels y otra 
ventana de 80x32 pixels. Según lo anterior, una ventana tiene las 
coordenadas de trazado de 0,0; 0,64; 64,0; 64,64; y la otra tiene las 
coordenadas 255,153; 175,153; 175,175; 255,175. Estas serán las coordena- 
das máximas y mínimas para el trazado dentro de ellas. Si deseamos hacer 
la segunda ventana de color cyan (azul-verdoso) y dibujar un círculo en 
ella, podríamos utilizar la rutina siguiente: 


100 FOR X = 175 TO 255 STEP 8 
110 FOR Y = 153 TO 175 STEP 8 
120 PLOT PAPER 5;X,Y 

130 NEXT Y 

140 NEXT X 

150 CIRCLE 215,164,5 


Naturalmente, podríamos imprimir en la misma zona con el empleo de 
un gráfico de bloques de color cyan para conseguir el mismo efecto. 
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CONTROL DEL 
MOVIMIENTO 


5.1 Teclas 


Es habitual en los juegos de aventuras, así como en los juegos de gráficos, 
controlar el movimiento del jugador mediante el empleo de un conjunto 
de teclas. En condiciones normales, éstas serían las teclas del cursor o las 
de flechas (con las flechas representando la dirección elegida) o las teclas 
N,S,E,W (correspondientes al norte, sur, este y oeste) o, en algunos casos, 
las teclas de números, sobre todo si se dispone de un teclado numérico. En 
la práctica, se podría utilizar cualquier conjunto de teclas y es posible 
definir un “teclado de gráficos”; es decir, un subconjunto del teclado 
constituido por 9 teclas en un cuadrado, con la orientación de las ocho 
teclas exteriores que representan los puntos de la brújula y la tecla central 
ignorada o utilizada para una acción especial, tal como el omnipresente 
“Hiperespacio”. En un teclado tipo QWERTY, el teclado de gráficos más 
probable es el sector mostrado en la Figura 5.1. 


Q W E 
A S D 
Z Xx 
Figura 5.1 . 


Una vez decidido el conjunto de teclas que controlarán el movimiento 
del jugador, tendremos que diseñar una rutina para interpretar el teclado. 


5.2 Desplazamiento de un protagonista 


El método utilizado para desplazar un jugador a través de los diferentes 
acontecimientos en un juego depende de la clase de juego y de la 
naturaleza de los sucesos. Si nuestro juego tiene una visualización 
constante de elementos gráficos, probablemente utilizaríamos el método C 
o D que se indica más adelante. Si, por el contrario, nuestro juego de 
aventuras es principalmente textual, probablemente utilizaremos un 
método como el denominado E. Sin embargo, los métodos más sencillos 
son los que he denominado A y B: A es un movimiento aleatorio y B es un 
movimiento aleatorio “con semilla”. 
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5.3 Metodo A: Movimiento aleatorio 


Tanto si nuestro juego de aventura es de tipo textual o de tipo gráfico, 
podemos efectuar el enlace entre los acontecimientos sucesivos de una 
forma meramente aleatoria. En este caso, no habrá ningún mapa como 
tal, porque el retorno a la misma “posición” puede dar lugar a un suceso 
diferente. Una estructura característica podría ser la que se indica en la 
Figura 5.2, 


1. EL JUGADOR DESPLAZA UN ELEMENTO 

2. GENERAR UN NUMERO ALEATORIO COMPRENDIDO ENTRE 
1 Y 3=R 

3. ELEGIR UNA SUBRUTINA DE ACUERDO CON R 

4. EFECTUAR LA SUBRUTINA ELEGIDA 


Figura 5.2 


En este caso, sólo son posibles tres clases de suceso, con la denominación 
de rutinas 1, 2 y 3. La elección de una rutina particular se efectúa 
solamente cuando el jugador hace un movimiento pero es aleatorio; esto 
es, sin que tenga relación con el movimiento realizado. Si el jugador se 
desplazó hacia el sur y luego hacia el norte (es decir, volvió a la misma 
posición), habria solamente una tercera parte de posibilidad de que el 
mismo suceso ocurriera en esa posición. Para una rutina de tal naturaleza, 
tiene poco sentido introducir un mapa en nuestro programa puesto que el 
“movimiento” del jugador es meramente ilusorio. 


5.4 Método B: Movimiento aleatorio “con semilla” 


Este método es probablemente el más económico en consumo de memo- 
ria, loque es de utilidad para máquinas con solamente una pequeña 
cantidad de RAM o para programas en donde se requiera una cantidad no 
habitual de memoria para almacenar datos. De forma simplista, consiste 
en que cada vez que se ejecuta el programa se generará un mapa diferente, 
pero ese mapa sigue siendo el mismo, inalterable, a través de todo el 
juego. El “*mapa” es realmente una serie de números, pero solamente un 
matemático muy capacitado podría predecir el mapa a partir del número 
inicial aleatoriamente elegido. El método actúa de la forma indicada en la 
Figura 5.3. 


1. UTILIZAR UNA FORMULA PARA CREAR UN NUMERO CON 
UN PUNTO DECIMAL 

2. PRESCINDIR DE LA PARTE ENTERA EN EL NUMERO 

3. UTILIZAR LA FORMULA PARA INDICAR LAS DIRECCIONES 
POSIBLES 

4, UTILIZAR LA FORMULA PARA CALCULAR LOS EVENTOS 

5. SIGUIENTE MOVIMIENTO 


Figura 5.3 
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Habida cuenta de que la fórmula es la misma y la secuencia de 
números también es la misma a través de todo el proceso, el resultado de 
la fórmula será el mismo en una “posición” particular cada vez que se 
ejecute. 

Una rutina del Spectrum para realizar esta operación se utiliza en el 
programa de Las Minas de Merlín en el Capítulo 6. Las líneas fundamen- 
tales son las líneas 1000 a 2220. La línea 2200 es en donde se utiliza la 
función aleatoria “con semilla” (semilla es el punto de partida para la 
generación de números aleatorios) para movimiento y la línea 8010 es en 
donde está definido. Cada uno de los dígitos en la parte decimal de este 
número se puede utilizar para controlar sucesos diferentes, como por 
ejemplo, el dígito 2 se utiliza para controlar la selección del suceso 
principal en la línea 546. 


5.5 Movimiento de pantalla completa 


Se trata de un método gráfico que desplaza un carácter, que puede ser uno 
del juego de caracteres del código ASCII, o bien un carácter predefinido, a 
través de la pantalla. Si deseamos utilizar un carácter definido por el 
usuario, dicha definición debe tener lugar antes de que se ejecute la rutina. 
Esencialmente, el método actúa visualizando el carácter en un cierto 
punto en la pantalla, con el empleo de PRINT AT, o, si se dispone de 
gráficos con mapas de memoria, se aplicará la función POKE a la posición 
de la pantalla. Cuando se desplace un espacio el carácter, será objeto de 
impresión en esta posición y ahora se le aplicará la función PRINT o 
POKE en la nueva posición. Por consiguiente, la rutina tiene las etapas 
siguientes mostradas en la Figura 5.4. 


. PRINT/POKE CARACTER EN POSICION ANTIGUA = PA 
. INTRODUCCION MOVIMIENTO 

. CALCULO DE LA NUEVA POSICION = NP 

. PRINT/POKE ESPACIO EN PA 

. PRINT/POKE CARACTER EN NP 

. LET PA=NP 

. GO TO 2 


Figura 5.4 


ZA OD Uh uyn 


Una rutina del Spectrum para realizar la anterior operación se indica en la 
Figura 5.5, que se utiliza en el programa de la Busca del Tesoro en el 
Capítulo 8. 

El método se hace más complicado si la pantalla sobre la cual se está 
desplazando el carácter no está en blanco por sí misma. No hay mucho 
que decir con respecto a tener una pantalla en blanco, pero tendremos que 
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aplicar la función PRINT o POKE en posiciones seleccionadas en la 
pantalla con caracteres que representen posiciones en el juego y, por 
consiguiente, encuentros posibles. Por ejemplo, supongamos que tenemos 
una rutina de lago y una rutina de castillo en nuestro programa. 
Representaremos al lago por una O y al castillo por * para simplificar las 
cosas, aunque los gráficos definidos por el usuario nos proporcionarán 
mejores resultados (ver Capítulo 8). 


800 REM DESPLAZA “p” ALREDEDOR DE LA PANTALLA 
890 LET x=0: LET y=0 

900 LET a$=INKEYS: IF a$=*"” THEN GO TO 900 
905 LET p=x: LET q=y 

910 IF a$=“5” THEN LET x=y-—1 

920 IF a$=“6” THEN LET y=y+1 

930 IF a$="7” THEN LET y=y-—1 

940 IF a$="“8” THEN LET x=x+1 

950 IF y>20 THEN LET y=20 

960 IF x>31 THEN LET x=31 

970 IFx<0 THEN LET x=0 

980 IF y<0 THEN LET y=0 

990 PRINT AT q,p;* ” 

1000 PRINT AT y,x;“p” 

1010 GO TO 900 


Figura 5.5 


El empleo de una pantalla con visualización en mapas en esta forma 
significa que tenemos que añadir dos subrutinas adicionales a nuestra 
rutina de movimiento. La primera subrutina debe comprobar si la nueva 
posición (NP) a la que se desplazará la figura contiene el lago o el castillo. 
Si fuera así, debe registrar dicho hecho (v.g., estableciendo un indicador) y 
efectuando la llamada del suceso correspondiente. La segunda rutina debe 
utilizar el indicador para una reimpresión del carácter del castillo o del 
lago después de que se haya desplazado la figura. Por consiguiente, lo 
primero sería similar a como se indica en la Figura 5.6. 


1. ¿ES LA SIGUIENTE POSICION (NP) UN ESPACIO? 

2. SI ES UN ESPACIO, ENTONCES VOLVER A LA RUTINA PRIN- 
CIPAL 

3. SINO FUERA UN ESPACIO, LLAMAR A LA RUTINA CORRES- 
PONDIENTE Y PONER EL INDICADOR AL NUMERO CORREC- 
TO 

4. RETORNO A LA RUTINA PRINCIPAL 


Figura 5.6 
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Si los gráficos que se están detectando tuvieran códigos de caracteres 
normalizados, estos últimos se pueden utilizar como los valores del 
indicador y, por consiguiente, pasarán a la segunda rutina, lo que sería 
como se ilustra en la Figura 5.7. 


1. SI EL INDICADOR SE PONE A 0 ENTONCES VOLVER A LA 
RUTINA PRINCIPAL 

2. DE NO SER ASI, SELECCIONAR EL CARACTER CORRECTO 
DE ACUERDO CON EL NUMERO DEL INDICADOR 

3. IMPRIMIR EN LA POSICION ANTIGUA EL NUMERO SELEC- 
CIONADO Y RETORNAR A LA RUTINA PRINCIPAL 


Figura 5.7 


5.6 El mapa de Ramtop 


Una rutina corta, que utiliza la codificación de máquina de BASIC (es 
decir, PEEK y POKE), se puede emplear para almacenar un mapa como 
una serie de octetos y otra rutina puede utilizarse para la llamada del 
conjunto de octetos alrededor de la posición del jugador actual para 
controlar el movimiento e imprimir el entorno. Esta técnica se puede 
emplear para fines simples o más complejos, pero el principio sigue siendo 
el mismo. En primer lugar, es necesario reservar suficiente memoria para 
almacenar el mapa de código de máquina. En el Spectrum, ello puede 
realizarse mediante la reposición de Ramtop y punteros reasignables 
similares para la posición más alta de la RAM del usuario existen para la 
mayor parte de los sistemas (v.g., HIMEN en BBC). La memoria 
reservada, debe ser como mínimo, tan grande como el número total de 
posiciones en el mapa. 

En esta área reservada, se aplica la función POKE a una serie de 
octetos, que representan cada uno a una posición en el mapa. Estos 
octetos pueden utilizarse, luego, como el código para una descripción de la 
posición actual del jugador o incluso para una representación en mapa 
visual directa. Consideremos lo último en primer lugar. Supongamos que 
el mapa es una serie de espacios dispuestos dentro de una matriz de 12 x 12 
posiciones posibles. Dentro de estas 144 posiciones posibles, 48 son 
espacios o recintos y 96 son paredes en blanco. A cada uno de los 48 
espacios se les da un número identificador y a las paredes en blanco se le 
asigna un 0, de modo que el mapa total tendrá el aspecto que se ilustra en 
la Figura 5.8. 

Entonces, después de cada movimiento, se puede mostrar la posición 
actual del jugador en el mapa visualizando las ocho posiciones que están a 
su alrededor, junto con su posición actual. Evidentemente, ello constituye 
un procedimiento adecuado si se utiliza en conjunción con el método de 
“teclado gráfico” de control del movimiento. 


64 


1 2 3 4 e) 6 7 8 9 10 11 12 

l 0 0 1 0 0 0 0 0 0 0 0 0 
2 0 0 Z 0 0 0 0 0 0 0 0 0 
3 0 12 3 4 Ss 24 0 0 0 0 0 0 
4 0 13 0 6 0 23 25 26 32 44 45 0 
5 0 14 0 7 21 22 0 0 33 0 0 0 
6 0 15 16 8 0 0 0 0 34 0 0) 0 
7 0 0-17 0 0 28 37 36 35 0 0 0 
8 0 0 18 19 20 27 0 0 38 46 47 0 
9 0 0 0 0 0 29 0 0 39 0 0 0 
10 0 0 0 0 0 30 0 0 40 0 0 0 
11 0 0 0 0 0 31 43 42 4] 48 0 0 
12 0 0 0 0 0 0 0 0 0 0 0 0 

Figura 5.8 


Si algunas de las posiciones circundantes son 0, serán objeto de 
visualización como un carácter de pared, tal como el bloque de gráficos 
por encima de la tecla 8 del Spectrum. Si fuera mayor que 0, la 
visualización será un espacio en blanco. De este modo, si el jugador está 
en la posición 9,11 en la matriz anterior, el mapa de su entorno sería como 


se ilustra en la Figura 5.9. 
Ñ 


NES 
ES 


Figura 5.9 


Cada vez que el jugador se desplace no solamente se actualizará el 
mapa, sino que también se realizará una prueba, de antemano, para ver si 
el jugador puede desplazarse a esa nueva posición; esto es, se realizará una 
prueba para ver si el siguiente octeto (posición) 0. Para utilizar dicha 
matriz, necesitaríamos reservar 144 direcciones y aplicar POKE a cada 
una de forma sucesiva, con el valor correspondiente. Las 12 direcciones 
primeras serán las posiciones 1,1 a 12,1 en nuestro mapa; las siguientes 12 
direcciones serán las posiciones 1,2 a 12,2 y así sucesivamente. Por 
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consiguiente, si la primera dirección es 32120 (en decimal), le aplicaríamos 
POKE 0 y, de forma análoga, procederíamos con la siguiente dirección 
(32121). Pero a la dirección 32122 se le daría el valor 1. Una forma fácil de 
conseguir dicha serie de POKEs es como sigue: 


500 LET P= 32119: REM UNO MENOS QUE LA DIRECCION DE 
COMIENZO 

510 FOR I= 1 TO 144: REM EL NUMERO DE OCTETOS 

520 READ A 

530 POKE P+LA 

540 NEXT 1 

550 DATA 0,0,1,0,0,0,0,0,0,0,0,0 

560 DATA 0,0,2,0,0,0,0,0,0,0,0,0 

570 DATA 0,12,3,4,5,24,0,0,0,0,0,0 

ETC. 


Para leer un mapa como el anterior comprobando los movimientos del 
jugador e imprimiendo el mapa, nos bastaría aplicar PEEK a los nueve 
octetos correspondientes. Si X es la posición horizontal del mapa e Y es la 
posición vertical, entonces, las posiciones alrededor del jugador serán 
x—1,y—1; x.y —1;x+1,y—1; x—1,y; x+1,y3 x-1,y +1; x,y+1;x+1,y+1. 
Sin embargo, el mapa se mantiene en memoria no como una matriz sino 
como una secuencia. Cada x es 1 y cada y es 12. Para encontrar el octeto 
deseado, debemos hacerle x+(y*12). De este modo, si el jugador está 
localizado en el punto 3,2 en la matriz, será x=3 e y=2, y necesitaremos 
leer el octeto situado en 32120 más 3 más 2*12=dirección 32147. Los 
octetos que rodean a la posición son, pues: 13 menos, 12 menos, 11 
menos, 1 menos, 1 más, 11 más, 12 más y 13 más. Podemos trazar los 
nueve octetos necesarios con el empleo de la rutina siguiente: 


600 LET P=32120 +X +(Yx*12) 

610 LET Q= PEEK(P— 13): IF Q=0 THEN PRINT AT (posición de la 
pantalla correspondiente) (gráfico bloque) 

620 LET Q= PEEK(P—12): IF Q=0 THEN PRINT AT (siguiente 
posición de pantalla) (gráfico bloque) 

etc. 


Esta búsqueda se puede reducir a una fórmula como se verá en la siguiente 
sección. 


5.7 El diseño del juego de enigmas 


Hemos empleado bastante tiempo en examinar la teoría y su método; 
ahora vamos a crear nuestro primer juego. Haremos un juego de enigmas 
para utilizar algunas de las técnicas de representación en mapa que 
acabamos de tratar, pero si hemos de tener un juego de enigmas antes de 
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nada precisaremos un enigma. Normalmente, adopta la forma de un 
laberinto, por lo que iniciaremos nuestro diseño con el mapa de nuestro 
laberinto. Puesto que se trata de un enigma que ha de resolverse tendrá 
una forma fija y no variará de un juego a otro. Sin embargo, puesto que 
vamos a utilizar un diseño modular, nuestro método permite que se 
utilicen las mismas rutinas con mapas diferentes. El juego se puede 
modificar completamente cambiando el mapa, si bien en términos de 
programación ello podría suponer simplemente cambiar cinco o seis 
sentencias DATA, o acaso solamente uno o dos centenares de octetos de 
información. Lamentablemente, sin embargo, suele ser algo más com- 
plejo. 

Ahora vamos a diseñar un mapa, después lo codificaremos y luego 
examinaremos las formas en que se utiliza la rutina en el juego y las 
formas que se pueden cambiar para juegos diferentes. 

El laberinto en un juego de aventuras es una combinación de desorien- 
tación (como en un laberinto real como el de Hampton Court) y de 
complejidad lógica (algo como un crucigrama). El laberinto lógico se 
puede considerar como un algoritmo o como un diagrama de flujo. El 
jugador ha de avanzar a través de todas las etapas del algoritmo en el 
orden correcto para conseguir el resultado adecuado a partir de un 
programa. El algoritmo es una serie de obstáculos que se han de superar. 
En condiciones normales, cada obstáculo o cada problema separado se 
resolverá llevando el objeto, u objetos, que se necesiten a una posición 
particular y efectuando las operaciones correctas con dichos objetos. 

La primera etapa de diseño es, pues, listar la secuencia de obstáculos o 
de soluciones. Podemos escribir cada posición de obstáculos como una 
posición de “necesidad” lo que significa que necesitaremos un objeto 
particular para pasar a través de esa posición y cada posición de solución 
como una posición de “consecución”, lo que significa que es el lugar 
donde el jugador (Cad) encontrará lo que necesita para superar una 
dificultad particular. En esta etapa, no necesitamos preocuparnos sobre 
cuáles podrían ser los obstáculos ni qué destreza se podría añadir a la 
relación obstáculo/objeto; simplemente dibujaremos un mapa de la 
secuencia de ““consecuciones” y “necesidades” requeridas para resolver el 
enigma total. Para cada posición de “necesidad” habrá, como mínimo, 
una “consecución”, aunque podamos tener algunas posiciones de ““conse- 
cuciones” sin otras posiciones de “necesidades”, por ejemplo, pistas falsas. 
Utilizaremos las letras del alfabeto para indicar que dos posiciones están 
enlazadas de esta forma. Asimismo, dibujaremos nuestro mapa a partir de 
la posición final (el objetivo del jugador) hacia atrás hasta la posición de 
partida. 

Este juego ha de denominarse el Trono de Camelot, por lo que 
haremos el objetivo del jugador que sea la propia Ciudad de Camelot. La 
anterior posición será el obstáculo final, por lo que será NEED Z. Por 
consiguiente, en la etapa inicial del programa habrá un cuadrado de GET 
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Z (consecución Z). Si actuamos hacia atrás de esta forma, concluiremos 
con una lista como la que se ilustra en la Figura 5.10. (En esta figura y en 
las siguientes, GET significa OBTENER y NEED significa NECE- 
SIDAD.) 


START 
GET J 
NEED J 
GET K 
GET L 
NEED K 
GET M 
NEED M 
NEED L 
GET N 
NEED N 
GET R 
GET Y 
GET P 
NEED Y 
GET Q 
GET H 


NEED Q 

NEED R Y NEED I 
GETZ 

NEED S 

NEED Z 

END 


Figura 5.10 


Si se tratara de una lista de posiciones sería algo semejante a un pasillo 
con una serie de recintos. Si el jugador avanzara a lo largo del pasillo de 
un recinto a otro, todos los obstáculos se encontrarán en el orden 
correcto. Ello no plantearía ninguna dificultad al jugador. Por ello, en 
lugar de seguir una línea recta o un pasillo, tenemos que dibujar un mapa 
que permita al jugador desplazarse a lo largo de muchos caminos 
diferentes y de esta forma, se le da varias opciones. Para hacerlo, podemos 
añadir posiciones “vacías”; esto es, posiciones que no tienen ninguna 
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importancia en el juego, aunque puedan parecer que lo tienen (tal como 
posiciones que contengan pistas falsas). Podemos dibujar un mapa de red 
de la forma siguiente: 


1. En primer lugar, dibujar el cuadrado de partida y un camino que salga 
de dicho cuadrado. 

2. Dibujar otro cuadrado con más de un camino de salida. En cada 
camino de salida, dibujar otro cuadrado. En cada uno de los cuadrados 
en blanco, escribir la letra E (como indicativo de vacio) o escribir la 
primera GET o cualquier NEED en su lista. En nuestro caso, se trata 
de GET J y de NEED J. De este modo, nuestro mapa tendría un 
aspecto similar al que se ilustra en la Figura 5.11. 


Necesidad 
J 


COMIENZO OBTENER J 


Figura 5.11 


3. El jugador no puede atravesar un cuadrado NEED hasta que haya 
pasado a través del cuadro GET correspondiente. En este caso, su 
recorrido sería START (Comienzo)-E-GET J-E-NEED J. Sin embargo, 
puede pasar a través de los cuadrados GET por lo que ahora dibujamos 
caminos fuera del cuadrado GET J. De esta forma no se puede 
conducir a otra cosa que no sea cuadrados GET, porque en la Figu- 
ra 5.10, nuestro mapa lógico, se dice que el jugador ha de pasar a través 
de NEED J antes de que reciba cualquier otra recompensa. Por consi- 
guiente, cada recorrido fuera del cuadrado GET J debe terminar en un 
cuadrado NEED, aunque los recorridos podrían pasar a través de 
cuadrados vacios. El camino del cuadrado NEED J debe conducir a la 
larga, a GET K, por lo que podemos añadir algunos cuadrados más, tal 
como se indica en la Figura 5.12. 

4. La siguiente etapa después de GET K es GET L, por lo que podemos 
añadir recorrido fuera de GET K que conduzca a GET L. Sin embargo, 
puesto que el jugador tiene ya K, se le podría permitir eludir L e ir 
directamente a NEED K. Si así lo hace, descubrirá, en una etapa 
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OBTENER 
K 


NECESIDAD 
J 


COMIENZO ri 


NECESIDAD 
Q 


NECESIDAD 
N 


NECESIDAD 
L 


Figura 5.12 


posterior, que necesita L, por lo que tendrá que revisar su estrategia, 
pero en esto es en lo que consiste el juego. La parte correspondiente del 
mapa será como se ilustra en la Figura 5.13. 

5. Observará que uno de los caminos que sale del cuadrado NEED K es la 
siguiente etapa en nuestro mapa; esto es, GET M. Otro es para NEED 
M, que es un extremo muerto hasta que se haya alcanzado GET M. 

6. Proseguiremos de esta manera cerciorándonos de que no hay ningún 
recorrido de que posibilite a un jugador para seguir su camino 
eludiendo etapas en nuestro diagrama de flujo elemental. No importa si 
ello se puede hacer de forma temporal; esto es, “cometiendo un error” 
(como haciendo caso omiso de GET L), en tanto que el jugador haya 
de volver atrás hasta dicho punto, a la larga. En la Figura 5.14 se 
muestra el mapa de red que utilicé para el programa del Trono de 
Camelot. Si usted sigue sus recorridos observará que tendrá que visitar 
todos los cuadrados para conseguir llegar a Camelot y que tendrá que 
pasar por la mayor parte de ellos en un orden determinado, pero 
también tendrá que volver sobre sus pasos en varias Ocasiones. 
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OBTENER 
L 


OBTENER 
K 
NECESIDAD 
J 


NECESIDAD 
K 


OBTENER 
J 


NECESIDAD 
N 


COMIENZO 


NECESIDAD 
0] 


NECESIDAD 
L 


De esta forma, hemos completado nuestro mapa de red básico, que 
combina la estructura lógica con la estructura del laberinto. Por consi- 
guiente podemos añadir un poco de variedad a la planificación. Diversas 
formas de hacerlo se tratan en otras partes de este libro, pero ahora 
daremos algunas sencillas como son: 


Figura 5.13 


l. Hacer que más de un objeto sea necesario para pasar a través de un 
cuadro NEED particular. observará que mi red incluye varios de estos 
objetos. 

2. Hacer que algunos objetos impidan al jugador pasar a través de 
algunos cuadrados, ello puede ser muy frustrante para el jugador, sobre 
todo si encuentra que un objeto que acaba de descubrir después de una 
larga búsqueda hace que se le mate en el recinto siguiente. 

3. Añadir enigmas adicionales o problemas suplementarios que actúen 
como cuadrados NEED; esto es, obstáculos, pero sin que se necesiten 
objetos ni soluciones de cualquier lugar en el juego. Por ejemplo, el 
jugador podría tener que descifrar un anagrama para proseguir su 
recorrido. Una rutina de anagrama se puede encontrar en el Capítulo 8. 
Añadiremos dos enigmas adicionales a Camelot. 
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OBTENER 


L 
17 
OBTENER 
? A 


OBTENER NECESIDAD NECESIDAD NECESIDAD 


N K M 
ENIGMA A OBTENER OBTENER 
1% ga. 


NECESIDAD OBTENER NECESIDAD 


OBTENER 
Ss H x 


Figura 5.14 


Una vez hecho todo lo anterior, podemos dibujar finalmente el mapa 
que vamos a almacenar en nuestro programa. Utilicese papel cuadriculado 
que proporcione suficiente espacio para todos los cuadrados necesarios en 
cada dirección. Tenemos que añadir algún espacio a nuestro mapa de 
modo que los únicos cuadrados que sean adyacentes entre sí sean aquellos 
que se puedan recorrer sucesivamente. Nuestro mapa no se dibujará como 
en la Figura 5.14, sino como se ilustra en la Figura 5.15, porque no es 
posible desplazarse directamente de START (comienzo) a GET N. El 
motivo para añadir estas separaciones y, por consiguiente, espacios vacios 
adicionales, es porque se irá a utilizar la rutina de visualización de mapas. 
Dicha rutina visualiza el cuadrado actualmente ocupado por el jugador y 
sus cuadrados circundantes, tal como se describe en la Sección 5.6. 

En la Figura 5.15 se muestra nuestro mapa completado para Camelot. 
Obsérvese las adiciones, que consisten en algunos espacios vacios adicio- 
nales, en que el cuadrado NEED R se ha hecho NEED R+1, en que el 
cuadrado NEED P se ha hecho NEED P— Y y que hay dos cuadrados de 
enigmas. 

Observará que el mapa está en una cuadrícula de 12x 14, lo que da una 
matriz de 168 cuadrados. Podríamos almacenarse en un array (conjunto 
ordenado), o en una serie de cadenas, pero para una mayor rapidez de uso 
y para mayor comodidad, le almacenaremos encima de Ramtop, utilizan- 
do el método descrito en la Sección 5.6. Observará que es fácil elaborar las 
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OBTENER 
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0 
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ECESIDAD| OBTENER 
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NECESIDAD 
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NECESIDAD 

Ss 


0 
10 
NECESIDAD) 
63 64 
FIN JECESIDAD 
x 


Figura 5.15 


sentencias DATA necesarias debido al retículo regular utilizado. Nos 
bastaría dar a cada cuadrado un número del 1 al 168 y almacenar estos 
últimos, pero no hay ninguna dificultad en almacenar números diferentes 
para todas las paredes en blanco, por lo que se pueden hacer 0 y los únicos 
cuadrados numerados son aquellos que el jugador podría atravesar. Cada 
sentencia de data puede ser una sola línea del retículo para facilitar su 
referencia, por lo que el código completo de nuestro mapa será las 
sentencias DATA mantenidas en las líneas 9500 a 9600 del programa. 
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(Obsérvese el contorno de ceros alrededor del mapa para evitar salirse 
de su borde.) Asimismo, observará que la posición de partida es el número 
17, el número final es 63, y que el número total de posiciones es 68. Ello 
puede parecer algo ilógico pero no afecta para nada a la naturaleza del 
juego (y también hace un poco más difícil el “engaño”). 

Una vez que se haya colocado el mapa en memoria con el empleo de la 
rutina anteriormente descrita, se puede efectuar la lectura correspondiente 
utilizando rutina incluida en las líneas 2070 a 2165 de Camelot. Las 
sentencias DATA también se pueden suprimir mientras se está ejecutando 
el programa si desea ahorrar memoria o para evitar que el jugador 
irrumpa en el programa y examine el mapa, pero para hacerlo sería 
necesario un programa de código de máquina. A medida que el jugador se 
desplace a través de la aventura, cada uno de los 68 números servirá de 
clave para la rutina correspondiente. Una forma de hacerlo sería utilizar 
una serie de líneas tales como: 


100 IF POSICION=1 THEN GOSUB 1000 
110 TF POSICION=2 THEN GOSUB 1010 
120 IF POSICION=3 THEN GOSUB 1020 
etc. 


pero necesitaríamos 68 líneas de esta clase. Algunas versiones de BASIC, 
tales como Microsoft BASIC y BBC BASIC tienen una GOSUB calculada 
que permite sentencias como: 


100 ON POSICION GOSUB 1000, 1010, 1020 


que actúa, de forma idéntica, a las tres líneas anteriores, pero el Spectrum 
BASIC no tiene esta función. Sin embargo, el Spectrum BASIC nos 
permite emplear variables en las sentencias GOTO y GOSUB. Por 
ejemplo, si todas las rutinas correspondientes a cada una de las 68 
posiciones están escritas en las líneas 6000 a 6689 de nuestro programa y 
cada rutina tiene 10 líneas, podríamos utilizar solamente una línea de 
BASIC para seleccionar la rutina correcta. Suponiendo que POSICION es 
la variable que almacena la posición actual del jugador, entonces: 


100 GOSUB (POSICION * 10)+ 6000 


hará el artificio. Si el jugador está en la posición de partida, número 17, 
esta línea enviará el control a una subrutina que comience en la línea 6170. 
Si el jugador está al final, número 65, el control se transmite a la línea 
6630 y así sucesivamente. Lo único que tenemos que recordar es que todas 
las rutinas de posición deben estar igualmente separadas. Si algunas 
posiciones tienen rutinas que son más largas que otras, ha de utilizarse la 
longitud de la rutina más larga como el intervalo entre rutinas. Por 
ejemplo, si una rutina tiene una longitud de 15 líneas pero todas las demás 
son de 6 lineas solamente, se debe considerar como separación las 15 
líneas. 
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La otra característica de este método de representación en mapas es la 
visualización resultante. Para poder probar la memoria y la inteligencia 
del jugador, no necesitamos visualizar el mapa completo de una sola vez, 
sino simplemente la posición actual y sus posiciones circundantes inme- 
diatas. Asimismo, necesitamos comprobar que el jugador no penetra ni 
atraviesa las paredes; esto es, que sólo puede desplazarse en un sentido 
permitido. Ambas cosas se pueden conseguir utilizando la clase de mapa 
que acabamos de almacenar en memoria. El método de visualización ya 
ha sido objeto de exposición. Si dispone de color en su microcomputado- 
ra, habrá de elegir dos colores para la pared y bloques abiertos que sean 
diferentes del color de fondo de la pantalla. De esta forma, se podrá 
observar con claridad el área completa así como el tipo particular de cada 
bloque. Ha de elegirse los colores de forma que se destaquen sobre un 
conjunto blanco y negro. Ha de tenerse presente, que las posiciones 
relativas de los octetos circundantes son tales como se indica en la tabla 
siguiente: 


Dirección Dirección 
Geográfica Lógica 
NW L-13 
N L-12 
NE L-11 
W L—1 
POSICION L 
E L+1 
SW L+11 
S L+12 
SE L+13 


¿Se puede reducir esto a una fórmula? Si, se puede hacer utilizando buclees 
FOR... NEXT, como se indica a continuación: 


10 REM M = PRIMERA DIRECCION DE POSICIONES DE 
MAPA 

20 REM A Y B SON COORDENADAS DE IMPRESION 

30 REM X ES OESTE A ESTE 

40 REM Y ES NORTE A SUR 

30. LET'A=2: LET 'B=2 

60 FOR Y=-—12 TO 12 STEP 12 

70 FOR X=-—1 TO 1 STEP 1 

80 LET P= PEEK(M+X+ Y): REM EXAMEN DIRECCION DE 
POSICIONES 

90 IF P=0 THEN PRINT AT A,B;**”:GOTO 110 

100 PRINT AT A,B;*“ >” 

110 LET B=B+1: REM DESPLAZAMIENTO A SIGUIENTE PO- 
SICION DE IMPRESION 


1 


120 NEXT X 

130 LET A=A+1: REM DESPLAZAMIENTO A SIGUIENTE 
LINEA DE IMPRESION 

140 NEXT Y 


Una rutina fácil similar puede utilizarse para probar los valores 0, 
comprobando que el jugador no está intentando atravesar una pared de 
ladrillo (algunas aventuras hacen que los jugadores consideren que ello es 
una acción bastante admisible). La ventaja principal de este método es que 
no se necesita ninguna comprobación compleja de la memoria de pantalla. 
El Spectrum organiza su mapa de la pantalla de una forma algo peculiar, 
que resulta difícil de procesar en un programa. utilizando nuestro propio 
mapa de lo que está en la pantalla, no necesitamos examinar en absoluto 
el propio mapa de pantalla del Spectrum. 


5.8 Rellenado del mapa 


Una vez que se haya diseñado nuestro mapa del enigma, que se le haya 
insertado en la memoria y que se hayan escrito rutinas para su examen 
para visualizar y actuar sobre lo que allí está, necesitamos saber lo que 
significa cada posición. Con solamente 68 posiciones, es posible tener una 
pequeña rutina para cada posición, pero es más fácil escribir bastante 
menos. Tendremos tres clases de rutina que son llamadas por la posición 
de mapa singular. Son las siguientes: 


l. Simplemente una rutina de visualización con una descripción sencilla. 

2. Una rutina de visualización, una descripción simple y una rutina que es 
también utilizada por otras posiciones. 

3. Una rutina de visualización, una descripción simple y una rutina 
singular para esta posición particular. 


De este modo, cada una de las 68 subrutinas implicará una descripción. 
Algunas tendrán rutinas adicionales, algunas de las cuales serán generales 
y otras serán especificas para la posición singular. Con miras a la sencillez, 
diremos que los cuadrados vacios (E) son de la primera clase, que los 
cuadrados de enigma, son de la segunda clase y que los cuadrados NEED 
y GET son de la tercera clase. 

Es en este punto cuando la creatividad, imaginación, humor, mapas de 
mente y diversión se introducen en el diseño. Cada uno de los 68 lugares 
necesitará una descripción, que puede ser tan simple como un “túnel” o 
tan compleja como se quiera. Más importancia tiene el hecho de que se 
tendrá que rellenar la lista de GETs y de NEEDs, que hasta ahora han 
sido una serie de abstracciones. La forma de trabajar es elaborar una lista 
larga de ideas felices, en una cantidad dos o tres veces mayor que la que se 
necesite, y luego seleccionar la que se adapte menos para la clase de juego 
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que desea. Ya puede tener algunas ideas basadas en la preparación general 
del juego, pero ahora ha de plasmarlas en palabras concretas. 

Una forma de hacerlo es elaborar una lista con tres columnas: Los 
nombres de los GETs/NEEDS (en nuestro caso, las letras del alfabeto, con 
algunas no utilizadas) los objetos (GETs) y lo que el objeto necesita (los 
NEEDS). Un ejemplo sencillo es que NEED J es ““una puerta cerrada” y 
GET J es “una llave”. Sin embargo, es preferible que la mayor parte de las 
relaciones no sean tan directas como ésta. De hecho, muchas aventuras de 
enigmas se pretende hacerlas lo más esotéricas posibles, con el frecuente 
empleo de juegos de palabras o de largas series de ideas para constituir el 
nudo de la cuestión. Por ejemplo, GET K podría ser ““un pato” y NEED 
K podría ser “un acantilado escarpado”. ¿Cuál es la relación? Si desean 
trabajar más tendrán que descender por el acantilado, pero resulta más 
fácil arrojar al pato (no resulta muy divertido, pero puede servir realmente 
para probar la inteligencia del jugador). 

Una vez que tengamos una lista completa de dichas relaciones tenemos 
todos los elementos básicos de nuestro juego. Es conveniente reunir 
alguna clase de enlaces temáticos, pero no es necesario. La lista de 
relaciones utilizadas en Camelot está en la Figura 5.16, pero si quiere 
ejecutar primero el juego, podría desear ignorar esta figura. 


Posición Destino 
Número Código Nombre cuadrado cuadrado Solución al problema 
(GET)  (NEED) 


l K Mono 2 24 Dar la clave del mono 

2 L Espada 9 35 Destruir manada de lobos 

3 I Pluma 56 53 Escribir con ella 

4 Y — Alzaprima 29 48 Apuntalar árbol caído 

S N Naranja 34 22 Da juego (en exceso) 

6 P Antorcha 39 44 Hacer ligera la roca 

7 J Brújula 28 10 Guía a través de la niebla 

8 Q Casco 62 42 Transporta agua para 
contrapeso 

9 H Rueda 49 61/59 Tiene un neumático (atavio) 

10 S Empalizada 67 65 Tiene una escala para 
trepar por acantilado 

11 X Cartas 68 64 Proporciona correo 
(protección) 

12 M Cuerno 46 26 Convocatoria 
Robin Hood 

13 Z Médico 

hechicero 60 SO Hace curas mágicas 
14 R Pergamino 14 33 Para escribir 
15 T Bananas 57 61 Peladas en la forma habitual 


TE 


Posición Destino 
Número Código Nombre cuadrado cuadrado Solución al problema 
(GET) (NEED) 


16 Arbol 

17 Signo (Estos nombres son 
18 Alacena comprendidos por el 
19 Lobo programa pero no son 
20 Torniquete partes fundamentales 
21 Roca de los problemas.) 
22 Jaula 

23 Bufón 

24 Gigante 

25 Carreta 

26 Ganso 

27 Juicio 

28 Neumático 

29 Escala 

30 Rio 

31 Acantilado 

32 Entorno 

33 Manada 

34 Cesto 

35 Correo 

36 Pelado 

37 Armadura 

38 Contrapeso 

39 Colmo 


Figura 5.16. Objetos: nombres, “gets” (obtener) y “needs” (necesidad). 


Ahora es principalmente una cuestión de escritura y de codificación de 
cada una de las rutinas de posiciones separadas. Ello puede requerir algún 
esfuerzo de concepción. 

Antes de la codificación, escribimos una lista de todos los objetos, que 
será nuestra lista de nombres y la acción, O acciones, que se pueden 
realizar con cada objeto. Además, necesitamos una lista de todas las 
descripciones de las posiciones diferentes. En cada posición de mapa se 
utilizarán dos tipos de rutina, uno que imprime la descripción incluyendo 
cualquier objeto existente y otro que acepta la entrada y da respuestas 
condiciones. La rutina de descripción tendrá, pues, dos componentes, pero 
el jugador no debe ser capaz de separarles. Una parte imprimirá simple- 
mente la descripción de la posición. El jugador no será capaz de 
manipular, o de responder a, esa salida en detalle. La otra parte 
mencionará cualquier objeto existente o, si los objetos están ocultos, una 
pista con respecto a la presencia de dicho objeto. 
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En términos esenciales, algo que puede retener una persona puede 
considerarse como una posición con su propia descripción. Algunos 
lugares normalmente utilizados se incluyen en la Figura 5.17. La descrip- 
ción puede ser tan larga y complicada como permita la memoria. Cuanto 
más larga sea tanto más interpretación necesitará por parte del jugador, 
pero una descripción que sea excesivamente larga sin ninguna interacción 
posible del jugador sólo servirá para que le resulte enojosa. Las posiciones 
deben ser lo más interesante posible. 

Trate de establecer las relaciones entre lugares de algún interés, en 
lugar de hacerlo de forma directa: “Penetra en otro recinto”. Los 
protagonistas pueden entrar y salir de edificios, subir y bajar a través de 
colinas y acantilados, atravesar hondonadas y ríos, penetrar en pasajes 
secretos, pasar bajo puentes, etc. Siempre que sea posible, pueden 
establecerse enigmas suplementarios haciendo problemática la entrada a 
una posición particular, aun cuando no dependa de un objeto a encontrar. 
Un ejemplo sencillo es introducir en la descripción una elección de rutas, 
de las cuales una sola es correcta, con las demás finalizando en una muerte 
repentina; un ejemplo sería describir dos recorridos traicioneros para 
descender por la cara de un acantilado, uno de los cuales se desmoronará. 
Más complicado puede ser posiciones que sean inalcanzables a no ser que 
se utilice la orden correcta, por ejemplo, para atravesar una corriente el 
jugador podría intentar SALTAR, VADEAR, BRINCAR, REMAR y 
CRUZAR antes de pensar en NADAR. Ello se utiliza en la posición 27 del 
Trono de Camelot como uno de los enigmas. 

Al elaborar descripciones de posiciones, hemos de hacerlas parecer en 
relación con los objetos allí existentes. Ello significa que tienen sentido 
para el jugador (lo que pudiera carecer de importancia si estuviéramos 
concibiendo un juego absurdo o sin sentido, tal como el basado en el 
cuento de Alicia en el País de las Maravillas) y que el aspecto importante 
de cada posición puede no ser patente al principio, con lo que se añaden 
más dificultades al jugador. 


CAMPO BOSQUE MONTAÑA PUENTE CASA 

MANSION CASTILLO CUEVA TUNEL RECINTO COFRE 
GUARDARROPA RELOJ COHETE VALLE AGUJERO FOSO 
CAJA PUPITRE COCHE CARRO CARRUAJE ARBOL 
NEVERA ALACENA VENTANA — ATICO SOTANO 

HUERTO BARRIL CHIMENEA BARCO BALSA TEJADO 
PLANICIE ESCALA ESCALERA ELEVADOR CALLEJON CAMINO 
VOLCAN GLACIAR PIRAMIDE DESIERTO PANTANO 

ARBUSTO ESTANQUE LAGO GLACIAR ISLA 

LAGUNA COLINA TEATRO ARRECIFE  HENDIDURA 
BARRANCO 

Figura 5.17 
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El programa contendrá las descripciones de Camelot en las líneas 6000 
a 6689. Puesto que disponemos de 68 posiciones, se tendrá 10 líneas para 
cada una. Observará que he añadido algunas pequeñas rutinas para 
aumentar la variedad del juego. El jugador puede llegar a considerar que 
son importantes, pero realmente no son necesarios. 


5.9 Desplazamiento de objetos 


El desplazamiento de los objetos disponibles alrededor del laberinto es el 
aspecto crucial del juego de enigma desde el punto de vista del jugador. Se 
le debe permitir tomar cualquier objeto en cualquier lugar, con tal de que 
puedan resolverse los enigmas necesarios. Por consiguiente, en cualquier 
etapa del juego necesitamos saber en dónde está cualquier objeto y qué 
objetos está transportando el jugador. El protagonista debe ser capaz de 
coger objetos (Camelot utiliza el verbo ordinario TOMAR para ello) y de 
abandonarles (Camelot utiliza DEJAR). Asimismo, podríamos permitir 
una orden de inventario de modo que se pueda recordar al jugador lo que 
está transportando. 

Camelot aborda estos problemas utilizando tres arrays; a saber, 
0(30,3), O$(15,13) e Y$(15,30). O(x,1) contiene la posición del objeto x; 
O(x,2) contiene la longitud del nombre del objeto en caracteres (con el 
objeto de evitar que el Spectrum inserte espacios suplementarios cuando 
leamos OS); OS(x) retiene el nombre del objeto x, que tiene hasta 13 ca- 
racteres de longitud e Y$(x) tiene la descripción asociada con el objeto x. 

Durante la inicialización, debe establecerse cada array, dándose a O() 
las posiciones iniciales de todos los objetos (líneas 8200, 8240 y 9300). A 
continuación, se pueden aplicar las rutinas siguientes: 


Para inventario del jugador (rutina que comienza en la línea 3010): 


FOR I=1 TO 30 
IF 0(1,1)=99 THEN PRINT 0O5(1,1 TO 0(1,2)) 
NEXT I 


Para describir los objetos en un recinto (rutina que comienza en la 
línea 5000): 


FOR I = 1 TO 30 
IF O(1,1) = POSICION THEN PRINT Y$(1), 
OS(1,I TO (0(1,2))) 
NEXT I 
Para coger un objeto (rutina que comienza en la línea 3070): 


LET 0(1,1)=99 
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Para tener un objeto (rutina que comienza en la línea 3090): 


FOR lI= 1 TO 30 
IF ES = OS(1,1 TO 3) THEN O(1,1) = POSICION 
NEXT 1 


Si se utiliza o destruye un objeto: 
LET 0(1,1) = 0 


Estas rutinas deben ser autoexplicatorias una vez que sepamos que 99 
significa que el objeto es transportado por el jugador. La primera rutina 
imprime una lista de todos los nombres de objetos que tienen el código 99; 
la segunda imprime todos los nombres de objetos y sus descripciones para 
todos los objetos que tengan el código de la posición actual; la tercera 
simplemente establece el código para la codificación de posesión; la cuarta 
busca el objeto incluido en el código de nombre de tres letras E$ y 
establece el código del objeto en correspondencia con la posición actual y 
la quinta cancela el objeto a partir del juego haciéndole corresponder con 
un número que no reconocerá ninguna de las otras rutinas. Por supuesto, 
no hay necesidad de que sean cero, pero suele ser la elección más sensible. 

Exactamente qué objetos son manipulados y en qué formas dependerá 
de las rutinas de verbos. Estas se describen en el Capítulo 7. 


El Trono de Camelot 


1 REM EL TRONO DE CAMELOT 

2 REM LA RUTINA PRINCIPAL SE 
INICIA AQUI 

3 REM AXAXARKAAKAAKAKA KA kkKk 

4 RESTORE 

5 CLEAR 65367 

6 LET fl=0: LET y=65425 

7 LET x=y 

10 GO SUB 8500 

20 GO SUB 8000 

30 BORDER 7 

40 GO SUB 2060 

42 REM AXXAKXKAXKKkkkkkk 

43 REM BUCLE PRINCIPAL COMIEN 
ZA AQUI 

44 REM AXAAAKAKkkAkkkkk 

45 REM muerte Q THEN GO TO 
9900 

50 GO SUB 999 

60 IF fl=1 THEN GO TO 45 

70 GO SUB 2970+ (verbx*20) 

80 IF ex=0 THEN LET f$=e$(1) 
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90 GO TO 45 
97 REM AXARARAA ALA kk k 


98 REM FINAL BUCLE PRINCIPAL 
99 REM AXXXARAKAKA kk kk 
859 PAUSE 1000 
997 REM XAXXXAXRXAXAKXKAKkkkk 
998 REM ENTRADA DOS PALABRAS 
999 REM *AXXXAXAARAA LA kk 
1000 LET a$=" de 
1005 INPUT ''Que sigue?,a$: IF a$ 
$="" THEN GO TO 1000 
1008 REM AXxXXXXkXkkkkk kk 
1009 REM DECLARAR VARIABLES COMO 
ESPACIOS 
1010 REM XXX Akk 
1011 LET k=0: LET b$=" “= LEF 
c$=" "* LET d$=" ": LET es$=" 


1012 IF LEN (a$)<3 THEN LET a$= 
a$4” ” 

1013 REM AXXXAAXXKkkkkkk 

1014 REM COMPROBAR AYUDA E INVEN 
TARIO 

1015 REM XXXAXXKXKAAKkkkk 

1016 IF a$(1 TO 3)="inv'" THEN L 
ET verb=2: RETURN 

1017 IF ASC(1 TO 3)="ayu" THEN L 
ET d$ ="ayu'"': LET verb=3: RETURN 
1019 FOR 1=1 TO 12 STEP 3: IF a$ 
(1 TO 3)=x$(1 TO 142) THEN LET 
dr=1: LET verb=1 

1022 NEXT 1: IF dr=1 THEN LET d 
r=0: IF verb=1 THEN LET e$(1)=a 
$(1): RETURN 

1025 FOR 1=1 TO LEN (a$) 

1030 IF a$(1)=" ' THEN LET b$=a 
$(1 TO (1-1)): LET c$=a$((14+1) T 
O LEN (a$)): LET k=k+1 

1040 NEXT 1 

1050 IF k<>1 OR c$="" THEN PRIN 
T ''Dos palabras por favor'': GO TO 1000 
1065 LET b$=b$+"  ": LET c$=c$+" 


1070 LET d$=b$(1 TO 3): LET e$=c 
$(1 TO 3) 

1075 LET fl=0: LET verb=0: LET n 
ombre=0 

1078 IF d$="go ' THEN LET t$=w$ 
: LET u$=e$: LET verb=1: GO SUB 
1200: IF fl=1 THEN RETURN 

1079 IF d$="go ' THEN LET b$="g 
o ': RETURN 
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1080 LET t$=v$: LET u$=d$: GO SU 
B 1200 

1084 LET verb=K+3: REM numero de 
verbo detectado 

1085 IF fl=1 THEN RETURN 

1090 LET t$=n$: LET u$=e$: GO SU 
B 1200 

1092 REM AXAXXKAHKHXKAA KA KK kk Ak kk 
1093 REM numero de nombre detec 
tado 

1094 ARAKXAKALHAKA RA KK A KA kk 

1095 LET nombre=K 

1096 PRINT '''"0,K." 

1099 RETURN 

1197 REM XA*XXXXXXAkAKAkAk 

1198 REM RUTINA PARA COMPARAR 
CADENAS DE PRUEBA Y RUTINAS 

1199 REM XAXAXAXHAXAKA kk kk 

1200 FOR 1=1 TO LEN (t$) STEP 3 
1210 IF t$(i TO 1+2)=u$ THEN LE 
T k=INT (1/3)+1: RETURN 

1220 NEXT 1 

1230 PRINT ''No comprendo '';a$: 
LET fl=1 

1240 RETURN 

1999 REM *AXXAXAXAXA AAA Ak 

2000 REM MOVIMIENTO 

2001 REM AAXXAKAARHAARA AA AR 

2002 IF nad=1 THEN LET ex=0: L 
T nad=0 

2003 TEM Comprobacion de barre 
ras 

2004 IF ex=1 AND es$S(1)<>f$ 

THEN LET e$(1)=f$: PRINT 

"Solo puede retroceder": 

PAUSE 500 

2005 LET x=y 

2006 LET ex=0 

2010 IF es$(1)="n'" THEN LET x=x- 


2020 IF e$(1)="s' THEN LET x=x+ 
2030 IF e$(1)="e'" THEN LET x=x+ 
2040 IF es$(1)="w'" THEN LET x=x- 


2050 IF PEEK (x)=0 THEN PRINT " 
terreno intransitable'': RETURN 
2055 CLS 

2060 LET posicion=PEEK (x) : LET 
Yy=X 

2064. REM ARAAARAARAA RARA AA AAA AR 
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2065 
2066 
2070 
2080 
2085 
2090 
2100 
2110 


REM VISUALIZACION MAPA 

REM AKKAKKAKKKKKKkKK KK ik ik 
LET a=2 

FOR c=-14 TO 14 STEP 14 

LET b=2 

FOR d=-1 TO 1 STEP 1 

LET p=PEEK (y+c+d) 

IF p=0 THEN PRINT AT a,b;" 


'": GO TO 2130 


2120 
2130 
2140 
2150 
2160 
2165 
2195 
2199 
cion 
2200 
2207 
2208 
2209 


3015 


PRINT AT a,b;" " 

LET b=b+1 

NEXT d 

LET a=a+1 

NEXT c 

PRINT AT 3,3;"5" 

PRINT AT 6,0="Estas "; 

REM Llamada rutinas de posi 


GO SUB (6000+ (posicion*10)) 
REM AXXKXAKXKAKAKA KK KA KK Ak kk 


REM Comprobacion de objetos 
REM OAXRAXAKARAA AA KK A KK KK KAR 
GO SUB 5000 

RETURN 

REM AKKKKKKKKKKKKKKKkK kk 
REM Control salidas 

REM AARAKAKKKKKKKKKK KK kk ik 
IF e$(1)="n" THEN LET f$=" 


IF e$(1)="s'" THEN LET f$=" 
IF e$(1)="e" THEN LET f$=' 
IF es$(1)="w" THEN LET f$=' 


RETURN 
GO SUB 2000: RETURN 


REM AXAXKAKHAKHA KK KK KK KK kk Ak 
REM Los verbos comienzan aq 


REM AX*AXAKAKA KA KA KK KK Ak 
REM Rutina inv 

REM AXAKAKAKHAKA KK KK KK KAR 
PRINT '' 

PRINT "Tiene:"; 

FOR i=1 TO 15: IF o(1,1)=99 


THEN PRINT TAB 10;0$(i,1 TO o( 


1,2) 


3017 
3020 


NEXT 1 
IF 0(10,3)>=2 THEN PRINT " 


una escala" 


3026 
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RETURN 


3027 REM AEAARAKAAK AA KK KK KA A A KAR 
3028 REM Rutina de ayuda 
3029 REM AXXXARHARKAAAHA LAA kk kk 
3030 IF posicion=2 OR posicion=3 
4 THEN PRINT "El problema esta f 
uera de mi comprension'': RETURN 
3031 IF posicion =35 THEN PRINT 
"Como actuaria con los Lobos?" 

: RETURN 
3032 IF posicion=13 THEN PRINT 
"Necesitamos un sentido de direc 
cion'': RETURN 
3033 IF posicion=24 THEN PRINT 
"El mono esta imitando sus accio 
nes'': RETURN 
3034 IF posicion=26 THEN PRINT 
''Si no puede resolverlo ha falla 
do'': RETURN 
3035 IF posicion=50 THEN PRINT 
"Quizas deba estudiar a fondo su 
remedio curativo'': RETURN 
3036 IF posicion=61 AND AND o(15 
,5)<5 THEN PRINT "parcialmente 
vestido no es muy atractivo. Que 
le parece un calzado?'': RETURN 
3037 IF posicion=61 AND p(9,3) 

5 THEN PRINT "Parece necesitar 
algun atavio'': RETURN 
3038 IF posicion=64 THEN PRINT 
"El armero nunca se mueve de su 
puesto'': RETURN 
3039 IF posicion=53 AND o(14,3)< 
2 THEN PRINT "Correcto?'': RETURN 
3040 IF posicion=59 THEN PRINT 
"En donde hay una voluntad hay 
un camino'': RETURN 
3041 IF posicion=48 THEN PRINT 
"Serame jor dejar lebien solo": 
RETURN 
3042 IF posicion=65 THEN PRINT 
"Oh querido! Esta trastocado"': R 
ETURN 
3043 IF posicion=42 THEN PRINT 
"Me quitare un peso de encima cu 
ando lo haya resuelto'': RETURN 
3044 IF posicion=53 THEN PRINT 
"Le cuenta una narracion de una 
situacion delicada'': RETURN 
3045 IF posicion=22 THEN PRINT 
"Simplemente necesita una tarjet 
a con el numero correcto de punt 
os'': RETURN 


3046 IF posicion=44 THEN PRINT 
"Lo siento yo tambien estoy a os 
curas'': RETURN 

3048 PRINT 'Pienso que lo esta h 
aciendo bien'': RETURN 

3049 RETURN 

3050 REM AXXAXKAKKKA KK KK KK KA kk 
3051 REM Mirar 

3052 REM AXXXXXXAARXKAKA KK A kk kk 
3055 1F c$(1 TO 3)="aro'" THEN G 
O SUB 5000: RETURN 

3056 IF nomb>15 THEN GO TO 3062 
3060 IF o(nomb,1)=99 OR o(nomb,1 
)=posicion THEN GO SUB 5100(no 
mbx*5): RETURN 

3061 PRINT ''No lo puedo ver": RE 
TURN 

3062 GO SUB 5100+ (nombx5) 

3066 RETURN 

3067 REM AXXAXKAKXAKAKKKKk KK A KA k kk 
3068 REM Tomar 

3069 REM AXAKAAKAAKKAKAK KK KA KK 
3070 LET g=0: FOR 1=1 TO 15: IF 
o(1,1)=99 THEN LET g=g+1: 

3071 NEXT 1: IF g>4 THEN PRINT 
''No puedes llevar nada mas'': RET 
URN 

3072 IF nomb=29 AND o(10,1)=99 T 
HEN LET a(10,3)=2: PRINT "Ahora 
tiene una escala'': RETURN 

3073 IF nomb=26 THEN PRINT "ELL 
a no vendra'': RETURN 

3074 IF nomb=28 AND o(9,1)=99 AN 
D 0(9,3)>2 THEN LET o0(9,3)=3:P 
RINT "Ahora tiene un neumatico": 
RETURN 

3075 IF nomb>15 THEN PRINT "No 
se movera'': RETURN 

3076 IF o(nomb,1)=99 THEN PRINT 
"Ya lo consiguio'': RETURN 

3077 IF posicion=59 AND nomb=9 T 
HEN LET 0(9,3)=3 

3078 IF posicion=0(nomb,1) AND o 
(nomb,3)>0 THEN LET o(nomb,1)=9 
9: RETURN 

3085 PRINT ''No esta aqui'': RETURN 
3088 RETURN 

3089 REM XAXXXXXAXAXKAkAKKkkkkkk 
3090 REM dejar 

3091 REM XAXAXXAXXAAKAKAA kk kk k kk 
3092 IF o(nomb,1)=99 THEN LET o 
(nomb,1)=posicion: RETURN 
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3094 PRINT ''No lo tiene'': RETURN 
3106 RETURN 

3107 REM XAXXXAXAKHKXAKAKk KK KK kk 

3108 REM dar 

3109 REM AXXXXAAKHKHA AAA A KK ik 
3110 IF posicion=22 AND nomb=39 
ABD 0(5,3)=2 THEN LET o(5,3)=3: 
LET nomb=5: LET ex=0: GO SUB 30 

90: RETURN 

3111 IF posicion=22 AND nomb=27 

AND 0(5,3)=2 THEN LET o0(5,3)=3: 
LET nomb=5: LET ex=0: GO SUB 30 

90: RETURN 

3112 IF posicion=61 AND nomb=36 
AND o0(15,3)=2 THEN LET o(15,3)= 

3: LET ex=0: RETURN 

3113 IF posicion=61 AND nomb=28 

AND 0(9,3)=4 THEN LET 0(9,3)=5: 
LET ex=0: RETURN 

3114 IF posicion=53 AND nomb=3 T 

HEN  LET 0(3,3)=2 

3116 IF posicion=53 AND o(14,3)= 

2 AND 0(3,3)=2 THEN LET ex=0 

3117 IF posicion=24 AND nomb=1 T 

HEN LET o0(1,3)=3: LET ex=0 
3119 GO SUB 3090 

3128 RETURN 

3129 REM AXARXXARKAAAAA ALA Ak kk k 
3130 REM Encender 

3131 REM AXXAXXAXAKAKA KK A KK k 
3132 IF nomb<>6 THEN PRINT '"'No 
ardera'': RETURN 

3134 IF o(nomb,3)>1 THEN PRINT 
"Ya esta encendida!'': RETURN 
3135 IF o(nomb,1)=99 THEN PRINT 
"La antorcha arde brillante": 

LET roca=3: LET o(6,3)=2: IF pos 
icion=44 THEN LET ex=0: GO SUB 
6446: RETURN 

3148 RETURN 

3149 REM AXAKHAAKAA KARA A AAA ARA 

3150 REM Pelar 

3151 REM AX AKAAAAAA A A 

3155 IF o0(15,1)=99 AND nomb=15 T 

HEN PRINT "Tiene una pila de cas 

caras de bananas": LET 0(15,3)=2 
: RETURN 

3157 IF 0(5,1)=99 AND nomb=5 THE 

N PRINT ''Tiene un puñado de mond 

as'': RETURN 

3159 PRINT ''No tiene nada que pe 

Lar'': RETURN 


4.—Williams 


87 


3168 RETURN 
3169 REM AXKAXAAKHARALA RA LA KA XA k 


3170.REM Llevar puesto 

3171 REM AXXAXXARXA AAA LAA AA KA kk 
3172 1F o0(11,1)=99 AND nomb=11 O 
R nomb=35 THEN PRINT 'Que figur 
a armada tan esplendida": LET 
0(11,3)=2: RETURN 

3187 RETURN 

3188 REM *XXXXXAXAXXAKAKXKk kk kk k 
3189 REM Llenar 

3190 REM AXXAXAKAKXKAAKA LAA KA Ak k 
3191 IF posicion=42 AND o0(8,11)= 

99 THEN GO TO 3212 

3192 IF o0(8,1)<>99 THEN PRINT " 
No tiene nada que llenar": RETU 
RN 

3196 IF posicion=27 OR posicion= 
41 OR posicion=35 OR posicion=36 
AND nomb=8 AND o0(8,1)=99 THEN 
LET 0(8,3)=2: RETURN 

3208 RETURN 

3209 REM XAXAAXXRXAKAKHAKK Ak AkA kk k 

3210 REM Vaciar 

3211 REM AXRXAXAAKXAKA KA kk KA kk k 

3212 IF 0(8,1)<>99 THEN PRINT " 
No tiene nada que vaciar'': RETUR 


N 

3213 IF o0(8,3)=1 THEN PRINT "El 
casco no esta lleno'': RETURN 

3215 IF 0(8,3)=2 AND posicion<>4 
2 THEN PRINT ''Que desperdicio": 
LET 0(8,3)=1: RETURN 

3218 IF 0(8,3)=2 AND posicion=42 
THEN PRINT "El torniquete abre 
": LET 0(8,3)=4: LET ex=0: RETUR 
N 

3229 RETURN 

3249 REM *AAXXAKAAAALH AAA KA kk kk 

3250 REM cortar 

3251 REM *AXXAAXARXKAKAAKAKAk kk kk 

3252 IF nomb=33 AND posicion=35 

AND 0(2,1)=99 THEN LET o(2,3)=2 
: LET EX=0: RETURN 

3254 IF o(2,1)<>99 THEN PRINT 

'" No tiene nada que cortar'': RET 

URN 

3256 PRINT "Un desperdicio de fo 
rtaleza" 

3266 RETURN 

3268 REM XAXAXARXAAARKKAAKk AA KAKAK KK 


3269 REM Soplar 
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3270 REM AXXAXHKAKHAKA AAA KK KK Ak 
3271 IF posicion=26 AND o(12,3) 
=1 THEN LET o0(12,3)=2: GO SUB 6 
262: LET o0(12,3)=1: LET EX=0: RE 
TURN 

3273 IF nomb<>12 THEN PRINT "U 
n desperdicio de aliento'': RETUR 


N 

3274 1F o0(12,3)<>1 THEN PRINT " 

No tiene un cuerno'': RETURN 

3285 RETURN 

3289 REM **XXARXARARKAHA LALA kk kk 

3290 REM Remediar 

3291 REM XAXAXXXAAARAK A KA k KA kk 

3295 IF nomb=9 AND posicion=59 A 

ND o0(9,1)=99 THEN LET o(9,3)=2: 
LET ex=0: GO SUB 3090: RETURN 

3300 PRINT '"No puede" 

3309 RETURN 

3329 REM XXXAAXAAAAKA AA KK kk kk kk 

3330 PRINT Comprimir 

3331 REM AAXXAXKRXARXKAKKAKkk kk kAkk 

3340 IF o0(5,1)=99 THEN PRINT "A 
hora tiene una bolsa llena"," de 
jugo'': LET o0(5,3)=2: RETURN 

3345 PRINT "Un desperdicio de f 

ortaleza'': RETURN 

3348 RETURN 

3349 REM XXXAXAXAKARKAAKAKAKAK kk 

3350 REM Nadar 

3351 REM XAXXAXXKAKAKHAKkAKKkkKkkAk 

3352 IF nomb=30 THEN LET nad= 
1: RETURN 

3368 RETURN 

3369 REM XAXXXXAAKAKAHA AA Kk kk kk kk 

3370 REM Trepar 

3371 REM AXXAAAAAAKAK KK Ak kk kk k kk 

3372 IF nomb=16 AND posicion=2 T 

HEN print s$ : LET 0(1,3)=1: RET 

URN 

3373 IF nomb=16 AND posicion=34 

THEN PRINT n$:LET o0(5,3)=1: RET 

URN 

3375 IF nomb=31 AND posicion=65 

THEN PRINT "Trepa a medio camino 
pero es demasiado escarpado. Ca 

e y...tortazo! Oh querido": LET 

muerto=1: RETURN 

3380 IF nomb=29 AND o(10,3)=2 AN 

D posicion=65 THEN PRINT "Trepa 

por el acantilado": LET ex=0 :LE 

T o(10,3)=3 
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3388 RETURN 

3389 REM XAXXXXKXAXAXAHK Ak KkkkKkk 
3390 REM Elevar 

3391 REM XXAXXAXAXAXKA ARA Ak kk 
3392 IF posicion=48 AND nomb=16 
AND 0(4,1)=99 THEN LET 0(4,3)=2 
: LET roca=4: LET ex=0: GO TO 340 


5 

3400 PRINT "Es demasiado pesado" 
: RETURN 

3405 PRINT "Lo eleva fuera del c 

amino” 

3409 RETURN 

4997 REM RKKKKAKKK KK KK KK Ak kk KA 

4998 REM Objetos en posicion 

4999 REM AXXXKAXAXAAKA RA LA kk kk 
5000 FOR i=1 TO 15 

5010 IF o(1,1)=posicion AND o(i, 

3)>0 THEN PRINT "Observa "';¿o$( 

1,1 TO (0(1,2)));y$(1): NEXT 1: 

RETURN 

5020 NEXT 1 

5030 RETURN 

5098 REM XAXXAXXAXXAXAkAkkkkkkAkk 

5099 REM Examen de objetos 

5100 REM AXAKKKKKKKKKKKKkKKkkKkAk kk 

5105 PRINT q$: RETURN 

5110 PRINT q$: RETURN 

5115 PRINT "Tiene una punta afil 

ada'': RETURN 

5120 PRINT q$: RETURN 

5125 PRINT "Esta lleno de jugo": 
RETURN 

5130 IF 0(6,3)<2 THEN PRINT " 

Esta apagado": RETURN 

5131 PRINT "Esta encendido'': RET 

URN 

5135 PRINT q$: RETURN 

5140 PRINT ''Tiene forma de cubo" 
: RETURN 

5145 PRINT "Es una rueda de bici 
cleta'": RETURN 

5150 PRINT "Esta rasgado”: RETURN 
5155 PRINT "Todos se han colocad 
o'': RETURN 

5160 PRINT q$: RETURN 

5165 PRINT "Esta haciendo un hec 
hizo'': RETURN 

5170 PRINT ''Esta en blanco": RET 
URN 

5175 PRINT 'Son muy atractivos”: 
RETURN 
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5180 IF posicion=34 AND o(5,1)=3 
4 THEN PRINT "Una naranja gigan 
tesca cuelga de el'': RETURN 

5182 IF posicion=2 AND o(1,1)=2 
THEN PRINT 'Hay un mono en el": 
RETURN 

5183 IF posicion=57 THEN PRINT 
"Estan llenos de bananas": LET o 
(15,3)=1: RETURN 

5184 PRINT q$: RETURN 

5185 IF posicion=5 THEN PRINT " 
Dice 'No iria mas alla'"," si yo 
fuera usted''": RETURN 

5187 PRINT q$: RETURN 

5190 IF POSICION=22 OR posicion= 
50 THEN PRINT "La puerta esta a 
bierta'': RETURN 

5192 IF posicion=14 AND o(14,1)= 
14 THEN LET o0(14,3)=1: PRINT "Ha 
y un pergamino en el polvo'': RET 
URN 

5195 PRINT q$: RETURN 

5200 IF posicion=42 AND o0(8,3) 3 
THEN PRINT "Hay un contrapeso v 
acio por el cierre'': RETURN 

5205 PRINT 'Es muy pesado": RETU 
RN 

5210 PRINT "Tiene un ganso'': RET 
URN 

5215 PRINT gq$: RETURN 

5220 PRINT "Parece como un escri 

bano": RETURN 

5225 PRINT 'Una rueda esta rota" 
: RETURN 

5230 PRINT "Tiene largas plumas 

de cola'': LET 0(3,3)=1: RETURN 
5235 PRINT q$: RETURN 

5240 PRINT q$: RETURN 

5245 PRINT "Es muy largo'': RETURN 
5250 PRINT q$: RETURN 

5255 PRINT "Parece no escalable" 
: RETURN 

5260 PRINT "Hay una escala plega 
da en el'": LET 0(10,3)=1: RETURN 
5265 PRINT q$: RETURN 

5270 IF posicion=67 THEN PRINT 
"Hay una escala plegada": LET o( 
10,3)=1: RETURN 

5285 IF posicion=62 AND o0(8,1)= 
62 THEN PRINT "El casco esta en 
buen estado'': LET o0(8,3)=1: RETU 
RN 
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5300 IF o(12,3)=0 THEN LET o(12 
¿3)=1 

5305 IF o(12,1)=46 THEN PRINT " 
Hay un cuerno en la ceniza" 

5310 RETURN 

5990 PRINT q$ 

5998 RETURN 

5999 REM AKAKAKAKK KK KK KK KK A KA A 

6000 REM descripciones de posici 

ones 

6001 REM XXXXXXAXAHALA LALA k kk 

6010 PRINT "en una ladera rocosa 
"7" con muchos cantos rodados su 
eltos” 

6019 RETURN 

6020 PRINT " por un arbol en La" 
» ladera" 

6029 RETURN 

6030 PRINT "en una ladera escarp 
ada'',''con arboles sin hojas" 

6039 RETURN 

6040 PRINT "en una senda sucia", 
"con muchos baches" 

6049 RETURN 

6050 PRINT "en una senda sucia.'”'," 
Junto a la senda hay una señal '' 
6059 RETURN 

6060 PRINT "fuera una gran tiend 
a ” 

6069 RETURN 

6070 PRINT "dentro de una carpa 
de circo.",'" Un malabarista le 
tira un cuchillo ','" pero falla" 
6079 RETURN 

6080 PRINT 'en un camino cubiert 
o ”"," de malas hierbas" 

6089 RETURN 

6090 PRINT "fuera una herreria." 
6099 RETURN 

6100 PRINT "en un camino bien co 
nservado,'': RETURN 

6110 PRINT "en una senda a tra 
ves de'",'un bosque sombrio"': 
RETURN 

6120 PRINT "en la cara norte'","" 

de una montaña": RETURN 

6130 PRINT "en un denso banco de 
niebla": IF o(7,1)<>99 THEN PR 
INT "Esta perdido": LET ex=1: GO 
SUB 2300 

6132 RETURN 
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6140 PRINT "en una alacena", "Ll 
ena de polvo'': RETURN 

6150 PRINT "en un claro de un bo 
sque'': RETURN 

6160 PRINT "en la cara sur'',' de 
la montaña'': RETURN 

6170 "en un camino'': RETURN 

6180 PRINT "en una encrucijada 
con'','' una señalizacion rota": 
RETURN 

6190 PRINT "por un barranco con"' 
, Un puente estrecho a su traves 

'": RETURN 

6200 PRINT "en un camino serpent 

eante'': RETURN 

6210 PRINT "por un barranco con 

'" "un puente de cables a su trav 

es'': RETURN 

6220 PRINT "en la Posada del Tah 

ur” 

6225 IF 0(5,3)<3 THEN PRINT "Ne 
cesita un naipe",'" para prosegui 
r'': LET ex=1: GO SUB 2300 

6229 RETURN 

6230 PRINT "en el patio de una p 

osada"': RETURN 

6240 PRINT "en un monasterio" 

6242 1F 0(1,3)<3 THEN PRINT "Un 

mono dice'''' 'Necesita una clave 
para seguir adelante'': LET ex= 
1: GO SUB 2300: RETURN 

6245 LET ex=0: LET f$=e5(1): PR 
INT "Puede pasar'': RETURN 

6250 PRINT "en el portico en un 

monasterio'': RETURN 

6260 PRINT ''en el Bosque de Sher 

wood.'''' De repente diez hombres 
armados le rodean." 

6262 IF o(12,3)=1 AND o(12,1)=99 
THEN LET ex=1: GO SUB 2300: R 
ETURN 

6264 IF 0(12,3)=2 THEN PRINT " 
Robin Hood al rescate!'"''" Los ho 

mbres armados huyen'"': LET ex=0: 
RETURN 

6268 PRINT "Le cortan la cabeza" 
: LET muerto=1: RETURN 

6270 PRINT "por un rio con un pu 
ente roto a su traves" 

6271 IFnad<>1 THEN LET ex=1: 
GO SUB 2300: RETURN 

6280 PRINT 'en una playa'': RETURN 


6290 PRINT "en unos establos'"': R 
ETURN 

6300 PRINT "en un cementerio'': R 
ETURN 

6310 PRINT "en la orilla de un b 
osque'': RETURN 

6320 PRINT 'por una cueva atranc 
ada'': RETURN 

6330 PRINT "en una caverna muy o 
scura'': RETURN 

6340 PRINT "en un naranjal'': RET 
URN 

6350 PRINT "en una ribera de rio 
un medio de ”,' veintiun lobos 
agresivos " 

6351 IF o(2,1)<>99 THEN PRINT " 
Le destrozan a dentelladas'': LET 
muerto=1: RETURN 

6353 PRINT "Temen a su espada": 
IF o0(2,3)<2 THEN LET ex=1: GO 
SUB 2300: RETURN 

6354 LET ex=0: LET f$=e5(1) 
6355 RETURN 

6360 PRINT "en una bahia rocosa" 
: RETURN 

6370 PRINT "en un campo arado": 
RETURN 

6380 PRINT ''en un sembrado'': RET 
URN 

6390 PRINT "en un corral de gran 
ja'': RETURN 

6400 PRINT "en una cueva estrecha" 

6401 IF o0(13,3)<2 THEN PRINT " 

Oye un alarido al sur" 

6402 RETURN 

6410 PRINT "en un camino sinuoso 
polvoriento'': RETURN 

6420 PRINT "en frente de," un t 
orniquete de hierro" 

6422 IF 0(8,3)<4 THEN PRINT "BL 
oquea su camino'': LET ex=1: GO 
SUB 2300: RETURN 

6423 LET ex=0: LET f$=e$(1): RE 

TURN 

6430 PRINT "en un camino pedrego 
so'': RETURN 

6440 PRINT "en un pasadizo": IF 
roca<4 THEN PRINT "obstruido 
con una enorme roca"'''" 

6442 IF roca<2 THEN PRINT "No 
puede proseguir': LET ex=1: GO S 
UB 2300: RETURN 
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6444 1F 0(6,1)=99 AND o(6,3)= 2 
THEN PRINT "Su antorcha hace qu 
e la roca",' sea mucho mas livia 
na'": RETURN 

6446 IF roca=4 AND 0(3,1)<>99 TH 
EN PRINT ''Su camino esta despej 
ado'"': LET ex=0: LET f$=e5(1): RE 

TURN 

6448 IF 0(3,1)=99 THEN PRINT ''S 

u pluma les hace cosquillas.",'G 
rita produciendo una enorme aval 

ancha.''" De repente se si 

ente bastante deprimido'': LET mu 

erto=1: RETURN 

6449 PRINT ''No puedo seguir adel 
ante": LET ex=1: GO SUB 2360: RE 

TURN 

6450 PRINT "en un tunel sinuoso" 
, estrecho'': RETURN 

6460 PRINT "en una granja " 

6465 IF 0(12,3)=0 THEN PRINT " 
con una chimenea humeante" 

6466 RETURN 

6470 PRINT "en un corral de gran 
ja'': RETURN 

6480 PRINT "en una senda estrech 

6481 IF 0(4,3)<2 THEN PRINT "qu 

e esta bloqueada por un ",'' arbol 
caido'': LET ex=1: GO SUB 2300: 
RETURN 

6482 RETURN 

6490 PRINT "en la entrada de una 
cueva'': RETURN 

6500 PRINT 'en una cueva humeda. 

"Hay una vieja gimiendo.",''Jun 
to a ella hay una jaula enorme." 
, Ella dice 'Si no curas",''mi do 
lor de cabeza te convertire'”,'en 

un sapo" 

6505 IF o(13,1)<>99 THEN PAUSE 
200: PRINT "Oh querido - te has 
convertido en un sapo": LET muer 
to=1: RETURN 

6507 PRINT "Gracias a Dios - un 
hechicero'': RETURN 

6510 PRINT "en un portillo enorm 

e'': RETURN 

6520 PRINT "en una gran escaler 

a", de piedra '': RETURN 

6530 PRINT "en una enorme torre 

de piedra.','Hay un gigante" 


6531 IF 0(3,3)<>2 OR 0(14,3)<>2 
THEN PRINT "Dice 'Dame algo"',"' 
para escribir al Rey Arturo'": L 
ET ex=1: GO SUB 2300: RETURN 
6532 PRINT ' garabateando alegre 
mente'': RETURN 

6539 RETURN 

6540 PRINT "en un valle estrecho 
'": RETURN 

6550 PRINT "en un paseo a una ma 
nsion'': RETURN 

6560 PRINT "en una gran jaula": 
RETURN 

6570 PRINT ''en una avenida de ar 
boles'': RETURN 

6580 PRINT "fuera en un lavadero 
'": RETURN 

6590 PRINT "en una carretera"' 
6591 IF 0(9,1)<>99 OR 0(9,3)<2 T 
HEN PRINT "en una carretera": L 
ET ex=1: GO SUB 2300 : RETURN 
$592 LET ex=0: LET f$=e$(1) 
6599 RETURN 

6600 PRINT ''en un paramo'': RETUR 


IN 

6610 PRINT "en un recinto. Hay " 
, un viejo vestido solamente con 

una toalla. Grita 'Me has",'"tra 

ido algunas ropas?'" 

6612 IF 0(9,1)<>99 AND o(15,1)<> 

99 THEN PRINT "NO!!! Un rayo 

relampaguea desde sus dedos y ", 

"de repente sientes un poco cham 

uscado'"': LET muerto=1: RETURN 

6614 IF 0(9,3)<>5 AND o0(15,3)<>3 

THEN PRINT ''Demelas" 

6616 IF 0(9,3)<>5 OR o0(15,3)<>3 
THEN PRINT "Que le parece el re 

sto?'': LET ex=1: GO SUB 2300 : R 

ETURN 

6618 PRINT "0.K. Puede pasar": 

LET ex=0: LET f$=e5(1) 

6619 RETURN 

6620 PRINT "en una armeria. "''" 

Hay una armadura ",''apoyada en u 

na pared'': RETURN 

6630 PRINT 'en Camelot. Bien hec 

ho'": LET muerto=2: RETURN 

6640 PRINT "en la puerta a Camel 

ot." 

6642 IF 0(11,3)<2 THEN PRINT "E 

L portero le tira.'",'0h querido, 
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sin armadura... ': LET muerto=1: 

RETURN 

6645 PRINT "El portero le deja e 
ntrar'': RETURN 

6650 PRINT "por debajo de un aca 
ntilado a pico'': IF o0(10,3)<3 TH 
EN LET ex=1: GO SUB 2300: RETUR 


N 

6655 LET ex=0: LET f$=e$5(1): RET 

URN 

6660 PRINT ''en un camino dorado" 
: RETURN 

6670 PRINT "dentro de un lavader 

O. ''''"Hay un cesto en una esqui 

na'': RETURN 

6680 PRINT "dentro de una biblio 

teca'': RETURN 

7998 RETURN 

7999 REM ARAAKKKAKKAKAKAKAKK kk kk Ak 

8000 REM Preparacion 

8001 REM XXXAXXAXAXHAKHKAA KA KA kk kk 

8004 LET dr=0 

8005 LET cart=0:.LET cabe=0: LET 
roca=0: LET arbol=0: LET lc=0: 

LET muerto=0: LET g=0: LET ex=0: 
LET +fS="" 

8010 LET v$="lootakleagivligpeew 

eafilempwricutblofixdresquswicli 
e 

8015 LET w$="n s e w  norsuro 

esest" 

8020 LET n$="monswofeacrooratorc 

omhelwhestolethorwitscrbantresig 
cupwolturroccagjesgiacargoojuity 
rladrivcliaropacbasmaipeearmcoud 

euchi” 

8030 LET s$="Suba arriba'"': LET n 

ad=0: LET q$='"No veo nada especi 

a L ” 

8035 LET x$="n s e uw " 

8040 LET verb=0 

81 01 REM AEKKKKKKAKAKKK KK KK A A 

8102 REM ****PONER NADA EN MEMOR 
TAX**x 

8103 REM AXAXXAXAXKHHAKKXkkKkkkkkk 

8104 LET p=65367 

8105 FOR i=1 TO 168 

8108 READ A 

8110 POKE (p+1),A 

8150 NEXT 1 

8200 DIM y$(15,30): DIM o(37,3): 
DIM 0$(15,13) 
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8210 FOR 1=1 TO 15: READ y$(1,1 
TO 30): NEXT 1 

8220 FOR i1=1 TO 15: FOR j=1 TO 2 
: READ o0(1,3]): NEXT j: NEXT 1 
8230 FOR i=1 TO 15: READ o$(1,1 
TO 13): NEXT 1 

8240 FOR i1=1 TO 15: READ o(1,3): 
NEXT 1 

8490 PAPER 7: INK O: CLS 

8498 RETURN 

8499 REM AXARXXAXAAARALA AA kk kk kk 

8500 REM instrucciones 

8501 REM XAXXAXXAHKAAA KA kk kk 

8520 BORDER 5: PAPER 1: INK 5: C 


8530 DRAW 0,2: DRAW 1,4: DRAW 2, 
5: DRAW 4,5: DRAW 5,6: DRAW 6,8: 
DRAW 7,9: DRAW 8,11 

8535 DRAW 8,20: DRAW 1,-10: DRAW 
1,70: DRAW 4,-20: DRAW 10,0 

8540 DRAW 1,15: DRAW 5,0: DRAW 1 
,10: DRAW 0,30 

8545 DRAW 0,-40: DRAW 2,-30: DRA 

W 10,-15: DRAW 0,-15: DRAW 2,0: 
DRAW 0,-20: DRAW 40,-15 

8550 DRAW 10,-20: DRAW 40,-10 

8560 PLOT 48,70: DRAW 0,8: PLOT 

60,99; DRAW 0,6 

8590 PRINT AT 10,18: INK 6;''CAME 
LOT" 

8595 INK 6 

8599 PAUSE 1000 

8600 BORDER 1: CLS 

8605 PRINT AT 2,12; PAPER 5; INK 
1;'""CAMELOT"" 

8610 PRINT AT 5,3;'"En Camelot ha 
ce un dia sombrio "” 

8611 PRINT AT 8,3;'Sus luces le 
ayudaran a encontrar el camino'' 

8612 PRINT AT 11,3;"Resolver lo 
s enigmas, seguir las pistas 

8613 PRINT AT 14,3;"Jugar con p 
alabras para obtener buenas not1 
clas " 

8614 PRINT AT  17,3;"Las ordene 
s me ayudan a jugar " 

8615 PRINT AT 20,3; Un verbo y 
luego un nombre O. Ko 

8620 PAUSE 500 


8621 CLS 
8622 PRINT AT 1,1;"Puede utiliza 
r las letras unicas", 2 Ny Sy 06 
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y W para movimiento.",,, 


8624 PRINT " y las palabras ' 
ayuda' y "," 'inventario pued 
en usarse"," por su pro 
pia cuenta.",,, 

8628 PRINT " Todas las demas 


ordenes deben ser '','" de dos pal 
abras y todas las palabras deben 
A ser minusculas." 

8650 PRINT AT 16,10= PAPER 6; IN 

K 1;"INICIALIZACION"” 

8652 PRINT AT 18,10; FLASH 1;'"Si 
rvase esperar" . 

8999 RETURN 

9047 REM *AXXXAXAXA LAA kk kkkkkkk 

9048 REM Datos para mapa 

9049 REM AXXXARARKAAALA RA Ak kk kk 

9050 DATA 0,0,0,0,0,0,0,0,0,0,0, 

0,0,0 

9100 DATA 0,0,1,2,3,4,5,6,7,8,9, 

0,0,0 

9110 DATA 0,0,10,0,0,0,0,0,11,0, 
12,0,0,0 

9120 DATA 0,0,13,0,0,0,14,0,15,0 
,16,0,0,0 

9130 DATA 0,17,18,19,20,21,22,23 
¿24,25,26,0,0,0 

9140 DATA 0,0,27,0,28,0,29,0,30, 
0,31,32,+3370. 

9150 DATA 0,0,34,35,0,36,0,37,0,38 
/0,39,0,40,0 

9160 DATA 0,0,41,0,42,43,44,45,4 
6,47,48,49,50,0 

9170 DATA 0,0,51,52,53,0,54,0,0, 

0,55,0,56,0 

9180 DATA 0,0,0,0,57,0,58,59,60, 

61,62,0,0,0 

9190 DATA 0,63,64,65,66,0,67,0,0 
,68,0,0,0,0 

9195 DATA 0,0,0,0,0,0,0,0,0,0,0, 

0,0,0 

9199 REM datos sobre objetos 

9200 DATA '"charlando",'en el sue 

lo", agitandose en la brisa" 

9210 DATA "en el terreno",” gran 

de y jugoso",'',''en una esquina" 

9220 DATA "en el suelo",'" en el 

terreno","cerca ",''en un monton 

en desorden'"' 

9230 DATA "en el terreno",'" en c 


uclillas en una esquina"',', andr 
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ajoso y raido",''apilado en el su 
elo" 

9297 REM XAXXAXARXAKALKAKAkKKKkkkk 
9898 REM Posiciones de objetos 1 
niciales y longitudes de nombres 
9299 REM AXKAAAAAAKA RA AA RARA A AR 
9300 DATA 2,9,9,8,56,9,29,10,34, 
9,39,8,28,10,62,9,49,8,67,11,68, 
10,46,7,60,13,14,9,57,10 

9397 REM XAAXAXARAARAHA Ak Ak kk kk 


9398 REM Nombre de objetos 
9399 REM AXARAAAARAAKAAARKA AA RA AR 


9400 DATA "un mono"',''una espada 
"una pluma",''una alzaprima",'u 
na naranja'',''una antorcha”,''una 
brujula",'"un casco”,'una rueda", 
"una media",''cartas',''un cuerno" 
, un hechicero",'"un pergamino"," 
bananas" 

9409 REM AXKAXAKAKHA KK KK KA ke 
9410 REM Datos sobre objetos ocu 
Ltos 

9411 REM AXAXAXAKXAKAKKKKAk kk Aki k 
9420 DATA 0,1,0,1,0,1,1,0,1,0,1, 
0,1,0,0 

9595 INK 6 

9897 REM XAXXAXAXKHALA RA KA KA kk kk 

9898 REM Final 

9899 REM AXXAXKAKHAK AA KK kk kk k 
9900 GO SUB 3010 

9995 PRINT "Otro juego?" 

9996 IF INKEYS$=""" THEN GO TO 99 

96 

9997 IF INKEYS="s' OR INKEYS="'S" 
THEN RUN 

9999 STOP 
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EL JUEGO 
6 DE COMBATES 


La parte fundamental de la mayoría de los juegos de aventuras es el 
sistema de combate. Muchos juegos de enigmas basados en el texto no 
tienen combate, pero la mayoría de los juegos con gráficos, o con 
características distintas del enigma central, implican combates. Ya hemos 
considerado algunos aspectos del método que se ha empleado para 
explorar las características del protagonista del jugador y de los mons- 
truos que podrían encontrarse. La mayoría de los seres que incorporamos 
a nuestro juego tienen alguna capacidad de combate. En realidad, en su 
forma más simplista, podría decirse que los monstruos son solamente 
capacidades de combate, que sirven para probar al protagonista/jugador, 
con miras a poder resolver un problema. Por tanto, es conveniente que 
tenga un buen conocimiento de su sistema de combate antes de que diseñe 
el protagonista del jugador o los monstruos, pues, de no ser así, podría 
encontrarse con que su sistema previsto no puede utilizar los valores que 
se han establecido. 


6.1 Valores y elección 


Para ver lo que está implicado en el sistema de combate de un juego 
procedamos como lo hicimos anteriormente: comienzo con un sistema 
simple y luego ir aportando adiciones graduales. Supongamos, pues, que a 
Sir Jon se le asignó solamente un valor 7, y que a todos los monstruos se 
les dio un valor en el margen de 1 a 9. Entonces, el combate podría ser una 
comparación simple de los dos valores, por lo que siempre que Sir Jon 
encuentre un monstruo su valor será objeto de comparación con el valor 
del monstruo y el que tenga el valor más bajo resultará muerto. 

Por consiguiente, nuestro diagrama de flujo podría contener las etapas 
siguientes: 


IF Valor de Sir Jon > valor del monstruo THEN monstruo muerto 
(= poner a 0) 


IF Valor del monstruo >= valor de Sir Jon THEN Sir Jon muerto (= 
puesto a 0) 


Podremos ver inmediatamente que se plantean problemas con un 
sistema tan simple. En primer lugar, el jugador no hace nada. Cad no 
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tiene ningún control sobre la situación, pues simplemente tiene que 
sentarse y observar si su héroe mata o es abatido. En el segundo lugar, no 
hay ninguna incertidumbre, por lo que no habrá riesgo ni ninguna 
recompensa. Cada vez que Sir Jon encuentra a un monstruo de 7 o más, 
resultará muerto; de no ser así, matará al monstruo. Ello sería muy 
enojoso y poco divertido de jugar, aun cuando fuera emocionante la parte 
gráfica correspondiente. 

Una forma sencilla de añadir incertidumbre sería hacer aleatorio el 
valor del monstruo. Sin embargo, si fuera completamente aleatorio, 
tendríamos el resultado opuesto; esto es, no habría ninguna posibilidad de 
predicción en absoluto. El jugador nunca sabría si luchar o huir, y el juego 
completo dependería de números meramente aleatorios. Resultaría poco 
satisfactorio si se perdieran muchos puntos debido a un número aleatorio 
simple. 

Por consiguiente la solución consiste en restringir el margen de valores 
para un monstruo particular, dentro del cual puede ser aleatorio. Supon- 
gamos que tenemos tres monstruos: un duende podría tener los valores de 
l a 7; un gnomo los valores de 3 a 8 y un gigante los valores 6 a 9. Ello 
significa que las posibilidades que tiene Sir Jon de batir a cualquier duende 
son de 6 entre 7; de batir a un gnomo son de 2 entre 3 y de batir a un 
gigante son solamente 1 de entre 3. Una vez que el jugador haya 
aprendido estas circunstancias a través de frecuentes encuentros, puede 
tener una medida de sus posibilidades valorando el riesgo y la recompensa 
potencial en cada situación. 

Por supuesto, podemos variar la configuración de los monstruos de 
otras formas. Por ejemplo, podríamos modificar la posibilidad de tener un 
valor particular. El duende anterior tiene una posibilidad de 1 entre 7 de 
tener el valor 1, un 1 entre 7 de tener el valor y un 1 entre 7 de tener el 
valor 4 (esto es, tiene la misma probabilidad para cada valor). De una 
forma más realista, y también más predecible, habría una mayor posibili- 
dad del valor medio, tal como se ilustra en el gráfico de la Figura 6.1. 

Dicha figura se trata de un diagrama de barras, o histogramas, que 
muestra 36 tiradas de dos dados con seis caras. La curva resultante es lo 
que se conoce como una distribución normal. De un total de 36 tiradas, 
solamente 1 sería 2, 2 serían 3, 4 serían 4, 2 serían 11, etc. Los extremos 
son menos probables que los valores medios, pero no obstante también 
son posibles. Podríamos conseguir dicha curva con cualquier margen de 
números que deseemos. Para obtener una curva en el margen de 1 a 7 para 
nuestro duende, tomaríamos un número aleatorio en el intervalo de O a 3 y 
se lo añadiríamos a otro en el intervalo de 1 a 4. En el Spectrum BASIC: 


100 LET R = INT(RND + 3) 

110 LET S = INT(RND + 3)+1 

120 LET MONSTRUO = R+S 

130 IF SIRJON > MONSTRUO THEN LET MONSTRUO = 0 
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Número 
de 
tiradas 


Puntuación 


Figura 6.1. Curva de distribución normal para la tirada de dos dados 


Podemos desarrollar fórmulas para asignar cualquier probabilidad a 
cualquier valor en el margen que se quiera, lo que proporciona una gran 
variedad en los monstruos, aunque la probabilidad lineal (la misma 
posibilidad) y la distribución normal suelen ser las únicas curvas utiliza- 
das. Algo que es importante recordar es que se debe buscar una 
compensación para que el jugador tenga, como mínimo, alguna posibili- 
dad de derrotarle. En el Capítulo 11 se incluye una rutina para permitir la 
utilización de márgenes diferentes de generación de números aleatorios en 
aventuras no basadas en microcomputadoras, que se pueden adaptar 
fácilmente para su empleo en los propios microjuegos. 

Volvamos al otro problema, que era el de la interacción del jugador. 
Todo lo que hemos añadido hasta ahora es la posibilidad de que el 
jugador, tras la enseñanza conseguida en juegos anteriores, pueda elegir no 
luchar contra un monstruo particular. Ello significa que se le debe dar una 
advertencia previa del monstruo o se le ha de dar una oportunidad de 
retirada cuando se encuentre con el monstruo. Es habitual que los avisos 
se den en una de dos formas. Una de ellas es que el protagonista disponga 
de algún dispositivo para buscar un sendero a seguir, tal como una 
lámpara, un globo mágico o radar y otra posibilidad es que aparezca una 
señal de aviso intermitente en la pantalla para indicar que ““un monstruo 
está cerca”, pero no se da ninguna señalización de cuán cerca está o en qué 
dirección aparecerá. Una rutina de lámpara se incluye en el juego que será 
al final de este capítulo. No obstante, resulta sencillo programar una 
rutina de aviso. Las etapas correspondientes son: 
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1. INSPECCIONAR LOS CONTENIDOS DE TODAS LAS POSICIO- 
NES ADYACENTES 

2. SI NINGUNA POSICION CONTIENE UN MONSTRUO ENTON- 
CES (THEN) FINALIZAR LA RUTINA 

3. SI (IF) UNA O MAS POSICIONES CONTIENE UN MONSTRUO 
ENTONCES (THEN) IMPRIMIR UN AVISO 


Por supuesto, el aviso no necesita darse en palabras. Por ejemplo, 
podría ser una señal de peligro intermitente o podría hacerse uso de las 
posibilidades acústicas de su microcomputadora en caso de que disponga 
de ellas. Si un jugador ha de responder a las señales visuales y auditivas así 
como a las palabras, tiene mucho más que aprender y que prestar mayor 
atención en el juego. 

La retirada puede incorporarse a los encuentros como una opción de 
combate. Un mecanismo ordinario es programar el combate en dos 
etapas: 


1. PREGUNTAR AL JUGADOR SI DESEA RETIRARSE O NO 
2. SIEL JUGADOR ATACA, IMPRIMIR LAS DIVERSAS OPCIONES 
DISPONIBLES, INCLUYENDO LA DE RETIRADA 


Si el protagonista se bate en retirada, probablemente el monstruo 
tendrá una posibilidad de alcanzarle por la espalda (lo que los jugadores 
de estos juegos bélicos conocen como “tiro libre”) y esta posibilidad puede 
ser dependiente de las velocidades relativas o de las destrezas del 
protagonista y del monstruo. La retirada podría ser automática a la 
posición anterior, en cuyo caso, ello podria recordarse por el programa, 
habitualmente mediante la puesta a 1 de un indicador, o podría ser en una 
dirección aleatoria, en cuyo caso, el personaje puede caer en la guarida de 
otro monstruo o en un peligro peor. 

Ello proporciona al jugador alguna opción, pero no demasiadas. Se 
necesitan otras variables y estas últimas se pueden añadir considerando las 
variables en un combate real. Hasta ahora, hemos examinado la aptitud 
relativa del protagonista y del monstruo y siempre en la opción de atacar 
o de retirarse. Asimismo, podemos modificar ambas situaciones, porque 
los contendientes suelen tener diferentes clases de aptitud. Una amplia 
distinción puede establecerse entre “aptitudes de ataque” y “aptitudes de 
defensa” y ambas se pueden desglosar adicionalmente en, por ejemplo, 
capacidades de armas arrojadizas, capacidades de armas purgantes, 
capacidades de apaleamiento, destreza manual, etc. Nuestro juego, nos 
limitaremos al ataque y a la defensa. 

De forma análoga, las opciones de ataque y de retirada se podrían 
complementar mediante otras opciones tales como el empleo de magia, la 
oportunidad de hablar con el oponente, la posibilidad de soborno, etc. 
Veremos si todas estas opciones se pueden incluir en nuestro juego de 
combate, pero, de momento, no utilizaremos ninguna de ellas. 
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Además de la capacidad y de una amplia gama de estrategia, el 
protagonista puede tener también una elección de armas y de elementos 
protectores (blindaje, armadura, etc.). Dichos elementos se pueden ofrecer 
al principio cuando se está preparando el juego o se puede encontrar o 
conseguir a través del mismo (en forma de recompensas locales) o bien, el 
jugador puede tener una selección permanente que lleve consigo. Utilizare- 
mos como opciones de armas las de espada, lanza, mangual y cuchillo y 
dispondremos de diferentes elementos de protección, incluyendo un 
escudo. Mientras que la totalidad de la armadura de protección se puede 
llevar de una vez, sólo se podrá utilizar una sola arma, por lo que el arma 
será una variable fluctuante a diferencia con la armadura protectora que 
será una variable acumulativa que proporciona una mejora en defensa que 
se hace cada vez más grande. 

Toda esta protección sería bastante pesada, por lo que el hecho de 
llevarla traerá consigo también una penalización acumulativa que podre- 
mos considerar como fatiga. También es posible utilizar armas de formas 
diferentes, tales como dar latigazos, empujar, abrirse paso por la fuerza, 
etc. Permitiremos una elección táctica simple para todas las armas, a saber 
“arriba” (con elebación del brazo) y “adelante”. Podemos considerar a 
“arriba” como una forma esencialmente defensiva pero adecuada contra 
grandes enemigos y enemigos que tengan capacidad de vuelo, mientras 
que “adelante” es de naturaleza esencialmente ofensiva, siendo convenien- 
te contra enemigos más pequeños y enemigos asentados sobre el terreno. 
La elevación del escudo es la mejor defensa, pero el movimiento hacia 
adelante del escudo es un elemento adicional al valor del ataque. 

Finalmente, algunos ambientes podrían afectar a algunas armas o 
estrategias y algunos enemigos pueden estar bien defendidos contra 
determinados ataques. Supongamos que los monstruos encontrados 
tuvieren su propia gama de protección y de armas así como diferentes 
estrategias preferidas, de modo que el jugador tendrá que aprender por 
experiencia lo que tiene un efecto más favorable contra oponentes 
particulares. 

Hay dos motivos para tener tantos niveles diferentes de complejidad. 
El primer motivo es que proporciona al jugador un gran número de 
opciones tácticas posibles y este último debe aprender cuál de ellas le 
proporciona las mejores posibilidades de victoria contra un oponente 
particular en una situación particular. Ello significa que el juego será un 
desafío durante un largo período de tiempo, teniendo mucho que apren- 
der. El segundo motivo es que todas estas variables se pueden incorporar a 
otros aspectos del juego, de modo que el combate no sea simplemente un 
aspecto separado e independiente. Por ejemplo, diferentes objetos mágicos 
pueden mejorar algunas capacidades o algunas armas o bien, reducir los 
ataques de enemigos determinados. También resulta posible atraer con 
señuelo a un enemigo a un lugar en donde el jugador sabe que una cierta 
táctica es muy satisfactoria; v.g., al espacio abierto en donde pueda 
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utilizarse un arco. La posibilidad de éxito del protagonista en un combate 
particular dependerá de si ha conseguido obtener la protección o el arma 
adecuada para un combate particular. 

Antes de examinar cómo podríamos plasmar todo lo anterior en el 
lenguaje BASIC, examinemos el combate del monstruo. A los monstruos 
se les podría asignar un conjunto de opciones, armas y elementos de 
protección que fueran idénticos a los disponibles para el protagonista. Si 
fuera así, cada momento del combate se podría determinar por una serie 
de elecciones aleatorias. Sin embargo, es más interesante dar a los 
monstruos diferentes unas estrategias también diferentes, de modo que, 
por ejemplo, los gnomos tiendan a atacar con “el mangual arriba”, 
mientras que los duendes tiendan a utilizar “la espada hacia adelante”. 
Los gnomos hostiles suelen tener cascos; los duendes agresivos suelen tener 
cotas de malla. De esta forma, ningún combate puede tener un resultado 
preestablecido. El jugador puede aprender que los gnomos agresivos, u 
ogros, tienden a hacer ciertas cosas, pero que no se puede tener certeza 
alguna de que cualquiera de ellos en particular puedan hacerlo así. 

También es conveniente dar a los monstruos unas opciones que no 
estén normalmente disponibles para el jugador. Un dragón, por ejemplo, 
podría ser capaz de arrojar fuego, un buitre podría ser capaz de volar y 
atacar desde arriba, un mago podría ser capaz de utilizar una varita 
mágica, etc. Si a los monstruos se les da varas mágicas, armas y 
armaduras protectoras, debe ser posible que dichos elementos les sean 
arrebatados por el protagonista victorioso una vez que los haya matado. 
Esta sería una forma obvia de recompensa directa por su victoria. 

Ahora bien, ¿cómo codificaremos todo lo anterior? 

Inicialmente, debemos decidir cuánta información se pone a disposi- 
ción del jugador. En unas condiciones extremas, no se podría dar ninguna 
información, como es el caso de un juego de enigmas, y se dejaría al 
jugador que descubriera, por sí mismo, qué armas, capacidades y 
monstruos estaban alrededor suyo y qué hacían. En el otro extremo, las 
instrucciones podrían indicar todas las posibles alternativas y cómo 
utilizarlas y en qué momento. Ambas condiciones extremas parecen ser 
poco atractivas, la primera porque el jugador se aburriría antes de 
aprender lo suficiente para ser capaz de desarrollar adecuadamente el 
juego y la última porque no habría ningún descubrimiento ni nada 
interesante que aprender. Por ello sería preferible proporcionar alguna 
información al jugador y hacerle descubrir y aprender el resto. De acuerdo 
con lo anteriormente expuesto, en nuestras instrucciones generales intro- 
duciremos lo siguiente: 


Este juego implica una elección de arma, tal como una espada y una 
lanza, y una elección de táctica, tal como “retirada” o “espada 
levantada”. Puede mejorar sus capacidades de ataque y de defensa, 
sobre todo apoderándose de elementos de protección. Hay muchos 
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monstruos a encontrar. Cada monstruo prefiere un arma y una táctica 
determinadas, pero no siempre las utilizarán. 


Durante cada lucha, la pantalla visualizará el arma, la táctica y la 
protección que están empleando ambos contendientes, junto con sus 
capacidades básicas de ataque y de defensa, de modo que el jugador se irá 
familiarizándose cada vez más con la gama de opciones y de variantes y, 
de forma gradual, se irá haciendo más capaz de predecir lo que es 
probable que ocurra. En términos generales, ésta es la forma en que las 
personas aprenden a luchar en la realidad, adquiriendo conocimientos de 
lo que es posible, de lo que es probable y de lo que puede hacerse en cada 
momento. Sin embargo, no efectuaremos una visualización de los cálculos 
que se están utilizando, de modo que el jugador sólo podrá observar los 
efectos de sus acciones y no las causas ocultas que están detrás de las 
funciones y de las rutinas del programa. 


6.2 Las Minas de Merlín 


Planifiquemos ahora un segundo juego de aventuras que prescinda de 
algunos de los defectos del juego de enigma, que titulamos el Trono de 
Camelot. Estos problemas son: 


1. Tiene una forma fija, por lo que no cambia cada vez que se ejecuta el 
programa correspondiente. 

2. Utiliza gran cantidad de memoria RAM. 

3. No permite mucha estrategia total y no tiene ningún elemento de 
combate, a diferencia con las aventuras de juegos no basados en las 
microcomputadoras. 


Lo que trataremos de diseñar es un juego que utilice solamente una 
cantidad de memoria relativamente pequeña, con variaciones de un juego 
a otro y permitiendo alguna clase de estrategia y de combate. 

Utilizaremos el método del mapa aleatorio ““con semilla” porque con 
ello se retiene toda la información sobre la aventura en una sola función, 
con lo que se evita la necesidad de mantener una representación en mapa 
compleja por separado en la memoria. Situaremos la aventura completa- 
mente bajo tierra en la forma tradicional, por lo que necesitaremos las 
órdenes de “arriba” y “abajo” en adición a las órdenes normales de los 
cuatro puntos cardinales. Llamaremos a este juego de aventura con el 
nombre de las Minas de Merlín. 

La función P=SQR(X*X+Y*Yx*Z) se utilizará para determinar las 
características de cualquier posición, en donde Y es la dimensión norte- 
sur, X, es la dimensión este-oeste y Z es la dimensión arriba-abajo. Habida 
cuenta de que deseamos tener un juego diferente cada vez, comenzaremos 
con valores diferentes para X e Y (pero no para Z), porque siempre 
iniciamos el juego al nivel del suelo con Z=1). Cada vez que se desplaza el 
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jugador, la función se utiliza para determinar qué salidas están a su 
disposición desde la nueva posición y solamente se permitirá el movimien- 
to en esas direcciones. Por consiguiente, el movimiento solamente implica 
cambiar los valores de X, Y o Z en cada ocasión y volver a calcular la 
función, disponiéndose una subrutina en las líneas 1000 a 1500 que se 
utilizarán con mucha frecuencia. 

Sin embargo, la misma función puede utilizarse para que aprendamos 
mucho más con respecto a cada posición. Lo que la función proporciona 
es la parte no entera de un número (esto es, la parte que sigue al punto 
decimal). El Spectrum nos da ocho digitos después del punto decimal. Si 
tomamos el valor de 0,4 como indicador de una conexión entre dos 
posiciones adyacentes y definimos una función correspondiente: 


DEF FNp() = SQR(X+*X+YxYx*Z)—INT(SQR(X+*X + Y+*YxZ)) 


entonces, podemos utilizar esta función los parámetros adecuadamente 
modificados para probar las salidas disponibles, tal como en las líneas 
1000 a 2220 del programa. El listado completo se da al final de este 
Capítulo. 

No obstante, la fórmula se puede utilizar también para proporcionar 
otra información acerca de una posición particular. Lo que la función está 
generando es un número pseudoaleatorio que siempre es, no obstante, el 
mismo para valores datos de X, Y y Z. Por consiguiente, le podemos 
utilizar como si se tratara de cualquier otro número aleatorio para 
determinar si los tesoros están en esa posición, o lo están los monstruos, o 
si ciertos Sucesos particulares son probables (y cuál es su probabilidad). 

Por ejemplo, supongamos que hay cinco posibilidades entre cien de 
que haya piezas de oro en cada posición. Tomamos cualquier parte de los 
ocho dígitos que tenemos en una posición particular, le transformamos en 
un valor comprendido entre uno y cien y vemos si dicho valor está por 
encima del limite de cinco. De este modo, si hemos de tomar una decisión 
sobre los dígitos uno y dos del número y el número es 0.044 856 47, 
necesitamos hacer lo siguiente: 


1. Multiplicar por 100 para obtener 04.485 647. 

2. Suprimir la parte decimal para obtener 0,4; esto es, 4. 

3. Ver si este número es inferior a 5, y determinar cuál es. 
4. Interpretar el resultado —hay algunas piezas de oro aquí. 


A continuación, podríamos desear calcular cuántas piezas de oro hay, 
para lo cual podríamos hacer uso de los digitos cinco, seis y siete. Con tal 
objeto, haremos lo siguiente: 


Multiplicar por 10.000 para obtener 0448.564 7. 

Suprimir la parte entera para obtener 0.564 7. 

Multiplicar por 1000 para obtener 564.7. 

Suprimir la parte decimal para obtener 564. 

Interpretar resultado —hay 564 piezas de oro en este lugar. 


Mao o 
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Naturalmente, si no existiera ninguna pieza de oro en este lugar, los 
digitos, cinco, seis y siete se podrían utilizar para otros fines; v.g., para 
calcular la fortaleza de un monstruo encontrado o como una variable para 
enviar el control a una subrutina. Si un dígito, o conjunto de dígitos, se 
utiliza para un fin particular, tal como calcular la cantidad de oro, 
también se puede utilizar para otros fines, pero ha de tenerse presente que 
ambas cosas habrán de estar relacionadas. Por lo tanto, si los mismos dígi- 
tos se utilizan para controlar una rutina que transforma al jugador en un 
enano y la prueba clave es si el dígito cinco es mayor que el cuatro, cada 
vez que se encuentren más de cuatrocientas piezas de oro el jugador se 
transformará en un enano. Sin embargo, ello se puede utilizar de forma 
ventajosa. Por ejemplo, supongamos que deseamos hacer que la recom- 
pensa por vencer a un monstruo esté directamente relacionada con el 
poderío de este último; en este caso, podemos utilizar los mismos digitos 
en el número aleatorio para calcular ambas variables. 

La rutina general para la realización de esta prueba y de este cálculo 
está incluida en las líneas 2800 a 2820. 

Mantendremos nuestro juego relativamente sencillo. No tendremos 
una visualización de mapa, pues en este caso no hay ninguno, pero 
proporcionaremos una relación verbal de las salidas desde cada posición. 
De este modo, se tratará de un juego simple aleatoriamente errático con 
un objetivo único: conseguir el mayor número de puntos posible. Sin 
embargo, emplearemos varias variables interrelacionadas de modo que 
cada decisión del jugador ha de tener en cuenta más de un factor. Estos 
factores serán sus facultades físicas, sus poderes mágicos, los poderes 
físicos y mágicos de los monstruos, el peso de los elementos transportados, 
su constitución general y el valor del tesoro. 

Cuando estemos utilizando una fórmula determinada, no será posible 
desplazar objetos alrededor del mapa porque no podemos cambiar el 
número en cada posición. Podríamos mantener un registro de objetos y de 
posiciones por separado, pero nuestro objetivo es ahorrar memoria y, por 
consiguiente, tendremos que admitir una limitación importante. Dicha 
limitación consiste en que en cualquier posición dada se tendrá la 
recurrencia de la misma clase de suceso, haciendo caso omiso de lo que se 
produjo con anterioridad. Por tanto, si la posición 11 tiene 247 piezas de 
oro en su primera visita, seguirá teniéndolas en todas las visitas sucesivas, 
aún cuando el jugador las haya tomado. 

Por consiguiente, debemos utilizar los números proporcionados por 
la fórmula no para conseguir rutinas o valores fijos, sino para otros que 
sean condicionales. Por ejemplo, si la posición ha de tener una rutina del 
tesoro podemos establecer que, algunas veces, el tesoro se encuentre allí 
y que, en otras ocasiones, se haya perdido. En consecuencia, el jugador 
tendrá que decidir si vale la pena el riesgo de volver a seguir sus propios 
pasos. 

Establezcamos ocho tipos de rutina en nuestro juego, que serán objeto 
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de llamada por el número aleatorio que también se utiliza para la 
mazmorra. Dichos tipos de rutina son: 


. Monstruos 

. Tesoro 

. Tesoro mágico 
. Pociones 
Armas 

. Accidentes 

. Antorchas 

. Alimento 


Ello significa que las variables del jugador requeridas, afectadas por 
estos sucesos posibles, deben incluir: 


1. Fortaleza C(1) 
2. Aptitud C(Q) 
3. Constitución CG) 
4. Conocimiento C(4) 
5. Alimento C(5) 
6. Carga máxima C(6) 
7. Dinero C(7) 
8. Dardos mágicos C(8) 
9. Pociones C(9) 
10. Valor de arma Codo) 
11. Valor de la armadura C(11) 
12. Carga C(12) 


Además, deseamos relacionar estos valores entre sí y dar al jugador la 
posibilidad de establecer su propia configuración de variables como la 
base de su juego. La forma habitual de hacerlo es permitir al jugador 
seleccionar tres o cuatro variables básicas (dentro de los márgenes 
establecidos) de las cuales dependerán todos los demás valores. Una vez 
que se hayan establecido estas variables, el jugador podrá * “comprar” dis- 
positivos de acuerdo con su idea de la forma en que jugará. Por lo tanto, 
comenzaremos con las variables FORTALEZA, APTITUD, CONSTITU- 
CION y CONOCIMIENTO. Cada una de ellas puede estar en el margen 
de 1 a 20 y el jugador será capaz de asignar doce de dichos puntos en 
añadidura al valor de base de 8 que tiene asignado cada una. 

Asimismo, el jugador comienza con un centenar de monedas de plata 
que puede gastar en la adquisición de aditamentos. Una vez establecida 
esta configuración inicial, el programa calculará todos los valores que se 
adaptan a las variables del jugador de acuerdo con la elección inicial de 
este último. 

Debe ser evidente que se trata de uno de los diseños más simples que 
corresponden a un juego de aventuras, pero que sigue siendo divertido de 
jugar. El resto de este capítulo se dedicará a describir los bloques 
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principales del programa de forma sucesiva y luego, examinar las clases de 
modificación que se puedan hacer para su mejora. En otros capítulos 
encontrará otras alteraciones que se podrían haber hecho y el mejor juego 
de aventuras será aquel que las combine todas de forma real y adecuada, 
junto con alguna forma de juego de enigma. El inconveniente consiste en 
que cada mejora trae consigo gastos de memoria. De momento, trabajare- 
mos sobre la base de un juego de interés mínimo. 

Comenzamos con una descripción de cómo se establecerán las varia- 
bles del protagonista del jugador. C(7) es una variable sencilla y directa 
(cada pieza de plata se añade al total). Los dardos mágicos serán un total 
similar de hechizos disponibles. Las pociones serán un inventario similar, 
de forma que cuando se beba cada poción se incrementará una de las 
cuatro características básicas del protagonista. El valor del arma se 
establecerá con respecto al valor del mejor arma encontrada hasta ahora y 
se sumará, O se restará, según se trate de ataque o defensa. 

La carga es el total de la suma de C(7)+C(8)+C(9)+C(10)+C(5) 
+C(11), mientras que la carga máxima es el producto de FORTALEZA y 
CONSTITUCION. El alimento es un número simple agotado cuando se 
come. El acto de comer eleva, de forma temporal, el valor de la 
CONSTITUCION. El valor del ataque será una fórmula derivada de los 
valores de FORTALEZA, APTITUD, táctica y arma. El valor de la 
defensa se basa también en FORTALEZA, APTITUD, táctica y arma. El 
ataque mágico está basado, de forma análoga, en el CONOCIMIENTO y 
APTITUD. 

El juego se dividirá en varios turnos, bajo el control de la variable 
CONTADOR, por lo que se puede calcular el agotamiento. Cada ocho 
turnos, el jugador perderá varios puntos de CONSTITUCION, lo que 
dependerá de la cantidad que se transporte expresada como una propor- 
ción del peso que sea capaz de transportar. Si el valor de la CONSTITU- 
CION se hace inferior a uno, morirá el protagonista. En cada turno se 
actualizan todos los valores, incluyendo el peso transportable y el peso 
transportado, por lo que el programa puede comprobar el grado actual de 
agotamiento. El acto de comer incrementará el valor de CONSTITU- 
CION, pero el transporte de la comida incrementará la magnitud de la 
carga. Por ello, el jugador debe equilibrar, en todo momento, el valor de 
los elementos que transporta y su valor potencial, en relación con la 
penalización acumulativa que corresponde a su transporte. Por consi- 
guiente, el problema básico sigue siendo el mismo que en el juego del 
enigma: qué transportar, a dónde y cuándo. 

Una vez que hemos bosquejado la configuración del protagonista, 
podemos pasar a las ocho subrutinas. El “monstruo” debe ser fácil de 
diseñar, aunque no lo sea de codificar. El jugador encontrará una posición 
que contenga un monstruo. Entonces, debe decidir si efectúa una retirada 
o si emprende una lucha. Si se elige la retirada, el monstruo dispondrá de 
un tiro libre hacia la parte posterior del protagonista. Si se elige la lucha, 
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debemos hacer que el jugador tenga la posibilidad de dar el primer golpe 
(esto es, que disponga del factor sorpresa), para lo cual utilizaremos la 
variable de APTITUD. Una vez decidido el orden para los golpes, el 
jugador y el monstruo elegirán, de forma sucesiva, si utilizarán un 
combate mágico o físico, calculándose cada golpe mediante la compara- 
ción del valor de ataque y el valor de defensa correspondientes, modifica- 
dos por un factor aleatorio. 

Ello significa que necesitamos disponer de una tabla de variables del 
monstruo que contengan el nombre del monstruo, sus valores de ataque y 
de defensa y su valor de APTITUD. Asimismo, se necesitará el valor de 
CONSTITUCION para que podamos calcular cuándo se le matará. 
Finalmente, habida cuenta de que la finalidad del juego es acumular 
puntos, necesitamos una fórmula para calcular el valor de cada monstruo 
matado. Para mantener la sencillez del juego, haremos que la fórmula sea 
la suma de todos sus valores antes de que se inicie el combate más un 
pequeño factor aleatorio. 

El “tesoro” debe ser también positivo o negativo, de modo que el 
jugador tenga posibilidades. Esparciremos varias guaridas de ladrones a 
través de todo nuestro recinto. En ocasiones, los ladrones estarán en un 
cierto lugar, en cuyo caso robarán algo del jugador. En otras ocasiones, no 
estarán presentes, por lo que el jugador puede apoderarse de parte de su 
tesoro. 

El “tesoro mágico” será relativamente raro pero estará disperso por 
todo el lugar. En su aspecto positivo, es capaz de servir de ayuda en un 
combate mágico, pero algunos tesoros serán pesados y otros estarán 
hechizados (esto es, servirán de ayuda al adversario). Resultará bastante 
fácil para el jugador descubrir el peso de un tesoro, pero solamente puede 
averiguarlo si está hechizado intentando utilizarle en combate. 

Las “pociones”, como tesoro mágico, se encontrará a través de todo el 
lugar, pero pueden ser ventajosas o estar hechizadas. Aumentarán o 
disminuirán una o más de las cuatro capacidades de básicas. 

Las “armas” pueden ser beneficiosas o perjudiciales, tener diferentes 
valores para el combate y puede ser su pago. En ocasiones, serán de su 
propiedad, pero, con frecuencia, estarán en posesión de alguien que desea 
venderlas. 

Los “accidentes” incluirán un conjunto heterogéneo de subrutinas que 
pueden variar desde caer a un pozo (con lo que se perderá CONSTITU- 
CION) hasta romper un arma, enamorarse de una hechicera y conseguir el 
CONOCIMIENTO MAXIMO. 

La rutina de “antorcha” proporcionará simplemente al personaje una 
antorcha o le privará de ella. Dicha antorcha se puede utilizar para 
descubrir la naturaleza del siguiente recinto antes de penetrar en el mismo. 
Sin embargo, algunas antorchas son ilusorias, por lo que pudiera ser que 
no revelaran la verdad. 

La rutina de alimento, producirá posiciones en las que se puede 
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encontrar comida. Será de pesos diferentes y algunas pueden tener un 
veneno suave incorporado. Otros alimentos pueden tener efectos mágicos, 
lo que podría elevar el valor de combate mágico del jugador o disminuir 
uno o más valores. 

Otros tipos de rutina de esta naturaleza se podrían añadir, de forma 
indefinida, hasta consumir toda la memoria disponible. Cada una de ellas 
debe afectar potencialmente a una o más de las variables del jugador, pero 
solamente, en casos extremos, deben dar lugar a la muerte instantánea. 
Habida cuenta de que dichos juegos son fundamentalmente aleatorios, la 
clave para hacerles interesantes es añadir la mayor cantidad posible de 
características y de variaciones e interrelaciones, de modo que siempre 
exista varias cosas sobre la que el jugador puede discernir. Cualquier 
pequeña modificación que pueda inventar, y que tenga este efecto, 
constituirá un perfeccionamiento del juego. En los capítulos sucesivos 
serán sugerencias, tales como la de conversar y las de soborno. 


Las Minas de Merlín 


5 REM 2950=validar 

6 REM 2900=borrar 
35 REM INSTRUCCIONES 
40 GO SUB 8500 

45 REM INICIALIZAR 

50 GO SUB 8000 

55 REM COMIENZO DE BUCLE PRINC 


59 REM impresion actualizacion 

60 LET CONTADOR=CONTADOR+1 

61 IF MUERTO=1 THEN GO TO 9900 

62 LET TURNO=TURNO+1 

65 GO SUB 2500 

69 REM INSTRUCCIONES 

70 GO SUB 500 

490 GO TO 60 

491 REM FINAL DE BUCLE PRINCIPAL 
495 STOP 

499 REM ENTRADA 

500 GO SUB 60 

504 REM MOVIMIENTO 

505 PRINT AT 0,8;'"CUAL AHORA?" 
508 PRINT PAPER 6; INVERSE 1;" 
B'"; INVERSE O;"eber.'; INVERSE 1 
7"C'"; INVERSE O;'"omer,'; INVERSE 
1;"D'"'; INVERSE O;'dejar un objet 
o,", INVERSE 1;"M'"; INVERSE 0;"0 
v,"; INVERSE 1;"R'"; INVERSE 0O;"e 
posar o utilizar una '; INVERSE 
1;"A'; INVERSE O;'"ntorcha?”, 


510 PRINT ''"Sirvase teclear la 
adecuada","'letra inicial." 

520 LET TS="MRLEDT"' 

525 GO SUB 2950 

530 GO TO 466+(CODE A$) 

534 GO SUB 5300: RETURN : REM B 
EBER 

535 GO SUB 5200: RETURN : REM C 
OMER 

542 GO SUB 5110: RETURN : REM D 
EJAR 

543 GO SUB 1000: REM MOV 

544 LET N=1000 

545 GO SUB 2800: IF MOVE=0 THEN 
RETURN 

546 GO SUB 4000+(Q*100): RETURN 
548 GO SUB 5400: RETURN : REM R 
EPOSAR 

550 GO SUB 5500: RETURN : REM A 
NTORCHA 

999 REM ordenes de entrada 

1000 REM 

1045 LET MOV=0 

1050 IF INDANTORC=2 THEN LET IN 
DANTORC=0: RETURN 

1051 IF MOV=2 THEN LET MOV=0: P 
RINT "ROCA SOLIDA'': RETURN 

1052 GO SUB 2900 

1055 PRIN AT 0,8;'"QUE FORMA?"" 
1055 LET TS="NSEWUD'': GO SUB 295 
0 

1090 IF A$C(1)="N'" THEN LET X=X- 
1: GO SUB 2000: IF MOV=2 THEN 
LET X=X+1: GO TO 1050 

1100 1F A$(1)="'"S' THEN LET X=X+ 
1: GO SUB 2000: IF MOV=2 THEN 
LET X=X-1: GO TO 1050 
1110 IF ASC(1)="E" THEN LET Y=Y+ 
1: GO SUB 2000: IF MOV=2 THEN 
LET Y=Y-1: GO TO 1050 

1120 IF AS(1)="W" THEN LET Y=Y- 
1: GO SUB 2000: IF MOV=2 THEN 
LET Y=Y+1: GO TO 1050 
1125 "IF AS(1)="U' AND Z=1 THEN 
PRINT "ESTA AL NIVEL DEL SUELO! 
'"": GO TO 1050 
1130 IF A$S(1)="U'" THEN LET Z=Z- 
1: GO SUB 2000: 1F MOV=2 THEN 
LET Z=Z+1: GO TO 1050 
1140 IF A$S(1)="D'" THEN LET Z=Z+ 
1: GO SUB 2000: IF MOVE=2 THEN 
LET Z=Z-1: GO TO 1050 
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1998 RETURN 

1999 REM MOVIMIENTO 

2000 GO SUB 2200: IF MOV=2 THEN 
RETURN 

2002 IF INDANTORC=1 THEN LET MO 

V=2: LET INDANTOC=2: LET N=1000: 
GO SUB 2800: RESTORE Q+9201: RE 

AD V$: PRINT "Hay "¿VS;'aqui'': R 
ETURN 

2005 GO SUB 2900: PRINT AT 0,0;" 
SALIDAS": LET MOV=0 

2010 LET X=X-1: GO SUB 2200: IF 
MOV=1 THEN PRINT ''NORTE"” 

2020 LET MOV=0: LET X=X+2: GO SU 

B 2200: LET X=X-1: IF MOV=1 THEN 
PRINT ''SUR” 

2030 LET MOV=0: LET Y=Y-1: GO SU 

B 2200: IF MOV=1 THEN PRINT 'ES 
TE" 

2040 LET MOV=0: LET Y=Y+2: GO SU 
B 2200: LET Y=Y-1: IF MOV=1 THEN 
PRINT "ESTE" 

2050 LET MOV=0: LET Z=Z+1: GO SU 
B 2200: LET Y=Y-1: IF MOV=1 THEN 
PRINT ''ABAJO" 

2060 IF z>1 THEN LET MOV=0: LET 
Z=2-1: GO SUB 2200: LET Z=Z+1: 
IF MOV=1 THEN PRINT "ARRIBA" 
2200 LET P=FN PO): IF P<.35 THEN 
LET MOV=2: RETURN 

2210 LET MOV=1 

2220 RETURN 

2499 REM IMPRESION ACTUALIZACION 
2500 FOR I=1 TO 12 

2502 IF CC(ID<O THEN LET C(I)=0 
2505 NEXT 1 

2510 LET CONTADOR=CONTADOR+1 
2515 LET LUCHA=C(2)+C(1)+C(10) 
2516 LET PUNTO=(MKx*5) +C (7) + CTURN 
*x2) 

2520 LET MAGICO=C(4)+C(2) 

2525 LET C(6)=C(1)*C(3)x*3 

2530 LET C(12)=C(7)+(C0(8)*(5)+C(9 
)+(0 01035) + (0(5)*2)+(0(11)*4) 
2535 IF C(12)>C(6) AND F<>1 THEN 

GO SUB 2900: PRINT AT 0,0;: PR 

INT "Esta transportando demasia 
do. Debe tirar algo.'": GO SUB 51 
DO : LET TIRAR=1 

2540 LET FATIGA=INT (C(C(CONTADOR/ 
8)*(0(12)/12))/(C(1))) 

2545 LET C(3)=C(3)-FATIGA 


2546 IF FATIGA .5 AND F=0 THEN G 

O SUB 2900: PRINT AT 0,0;''Se est 
a sintiendo agotado" 

2550 IF C(3) 1 THEN PRINT ''Se de 
smaya por fatiga y ese es su fin 

al.'': GO TO 9900 

2552 LET C(6)=C(1)*C(3)*3 

2553 LET C(12)=C(7)+(C(8)*5)+C(9 
)+(0(10)*5)+(0(5)*2)+(0(11)*4) 
2554 PRINT AT 15,12;" '= PRINT 
PS 

2555 PRINT AT 15,12;INT C(ANTORCH 
A +0.9) 

2556 PRINT AT 15,29;PUNTO 

2557 FOR I=1 TO 4 

2558 IF CC(1)>20 THEN LET CC(I)=2 


0 
2559 NEXT 1 
2560 FOR I=1 TO 6 
2565 PRINT AT 154+1,12¿".  " 
2570 PRINT AT 15+1,12;CC1) 
2575 PRINT AT 15+1,29;"  " 
2580 PRINT AT 15+1,29;C(1+6) 
2585 NEXT 1 
2590 IF TIRAR=1 THEN LET TIRAR= 
0: GO TO 2515 
2699 RETURN 
2799 REM PARA ESTABLECER CONTROL 
ENTERO 
2800 REM DESPLAZA TODOS LOS ENTE 
ROS NO PERTINENTES MAS ALLA DEL 
PUNTO DECIMAL 
2805 LET Q=(P*N/10))-INT  (Px(N/ 
10») 
2809 REM DESPLAZA EL ENTERO REQU 
ERIDO Y PRESCINDE DEL RESTO 
2810 LET Q=INT  (Qx10) 
2820 RETURN 
2899 REM BORRAR VENTANA SUPERIOR 
2900 PRINT AT 0,0 
2905 FOR I=0 TO 8 
2910 PRINT AT 1,0;" 

mo 
2915 NEXT 1 
2918 IF BORRASUP=1 THEN RETURN 
2920 FOR 1=9 TO 14 
2923 PRINT AT 1,0;" 
2924 NEXT 1 
2925 RETURN 
2949 REM VALIDAR ENTRADA 
2950 LET A$=INKEYS 
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2952 LET KT=0 

2955 IF A$="" THEN GO TO 2950 
2960 IF CODE A$>90 THEN LET A$= 
CHR$ (CODE A$-32) 

2964 PRINT AT 11,0;'"Ha tecleado 
"AS 

2965 FOR 1=1 TO LEN (TS) 

2970 IF TS(I)=A$ THEN LET KT=1 
2975 NEXT 1 

2980 IF KT=1 THEN RETURN 

2985 GO TO 2950 

2998 RETURN 

2999 REM RUTINAS DE COMBATE 

3010 PAUSE 100: GO SUB 2900 

3020 PRINT AT 0,0;"Desea retirar 
se, utilizar un dardo magico o c 
ombate fisico?" 

3030 LET TS$='PBR" 

3040 GO SUB 2950 

3050 IF A$(1)="P" THEN GO TO 33 


3060 IF A$S(1)="B" THEN GO TO 32 


3070 LET R=FN R(3) 

3080 IF R>1 THEN GO SUB 2900: P 
RINT AT 0,0;"Escapa ileso'': LET 

RETIRADA=1: RETURN 

3090 GO SUB 2900: PRINT AT 0,0;" 
No puedo pasar'": LET RETIRADA=2 
3100 RETURN 

3200 IF C(8)<1 THEN GO SUB 2900 
: PRINT AT 0,0;"No tiene ningun 

dardo magico'': PAUSE 5000: GO TO 
3010 

3205 LET R=FN R (40) 

3210 LET C(8)=C(8)-1 

3220 IF R>MAGICO THEN GO TO 326 


0 

3230 PRINT AT 0,0;'"Su dardo magi 
co envia el '"M$;'"devanador”' 

3240 LET M(2)=M(2)-FN R(12) 
3250 RETURN 

3260 GO SUB 2900: PRINT AT 0,0;" 
Fallo'': RETURN 

3300 GO SUB 2900: PRINT AT 0,0;" 
Arma arriba o adelante?" 

3310 LET TS="UF" 

3320 GO SUB 2950 

3325 LET AU=-1 

3330 IF A$="F" THEN LET AU=1 
3340 LET AD=LUCHA-M(1) 

3350 LET AD=INT (CFN RC(AD))/2) 
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3360 LET AD=AD+AU-DU 

3370 LET DF=INT C(FN R(M(5)>/2) 

3380 IF DF>AD THEN GO SUB 2900: 
PRINT AT 0,0;"Un fallo": PAUSE 
100: RETURN 

3390 LET DANO=INT (FN R(CC(10)+CC 

1))-FN R(M(5))3) 

3400 IF DANO<1 THEN LET DAÑO=1 

3401 LET M(2)=M(2)-—DANO 

3405 GO SUB 2900: PRINT AT 0,0;" 

Puede causar '';DANO;' daño" 

3406 PAUSE 100 

3410 RETURN 

3499 REM COMBATE DE MONSTRUO 

3500 LET R=FN R(M(3)) 

3510 LET S=FN R(M(4)) 

3520 LET DU=1 

3530 IF S>1 THEN LET DU=-1 

3540 IF R>1 THEN GO TO 3600 

3550 IF M(3)<2 THEN GO TO 3600 

3560 LET R=FN R(20) 

3570 IF R>M(1) THEN GO TO 3595 

3580 GO SUB 2900: PRINT AT 0,0;" 

Un dardo magico se dispara y le 

golpe'':: PAUSE 50 

3585 LET C(3)=C(3)-FN R(3) 

3590 RETURN 

3595 GO SUB 2900: PRINT AT 0,0;" 

Un dardo magico pasa raudo sobre 
su cabeza"; PAUSE 50: RETURN 

3600 LET DA=(FN R(M(1)+M(6))/2) 

3610 LET DA=DA+DU-AU 

3620 LET AF=INT (FN R(C(11)+2)) 
3630 IF DAXAF THEN (GO SUB 2900: 
PRINT AT 0,0;"El monstruo le a 
comete pero falla!!!'": PAUSE 50: 
RETURN 

3640 LET DANO=FN R(3) 

3650 GO SUB 2900: PRINT AT 0,01; 
"Le ha golpeado": PAUSE 50 

3660 LET C(3)=C(3)-DANO 

3670 IF C(3)<0 THEN LET C(3)=0 
3675 PRINT "Y sufre '"¿DANO;' dan 
o'': PAUSE 50 

3680 RETURN 

4010 GO SUB 2900: PRINT AT 0,01; 
"He aqui un gitano errante. Tien 
e algunas gangas tremendas si ti 
ene suficiente dinero." 

4011 PAUSE 100 

4012 LET R=FN R(3): IF R=3 THEN 
GO SUB 8400: RETURN 
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4015 LET R=FN R(4) 

4020 LET S=FN R((C(7)/2)+(Rx*4)) 

4030 PRINT BS(R);" para "¿S'" pi 

ezas de plata." 

4035 PAUSE 100 

4040 PRINT "Cuantos quiere?" 

4045 INPUT T: IF T*S>CC(7) THEN 

PRINT "No sea necio'': PAUSE 100: 

GO SUB 2900: PRINT AT 0,0;: GO 

TO 4030 

4050 LET C(7)=C(7)-(T*S) 

4055 GO TO 4055+r 

4056 LET C(5)=C(5)+T: RETURN 

4057 LET C(10)=C(10)+T: RETURN 

4058 LET ANTORCHA=ANTORCHA+T: RE 

TURN 

4059 LET C(9)=C(9)+1: RETURN 

4099 RETURN 

4100 LET R=FN R(20) 

4101 IF R>SQR (PUNTO)+5 THEN 6G 

O TO 4100 

4102 GO SUB 2900 

4103 LET BORRARSUP=1 

4105 RESTORE 9249+R 

4106 LET KM=R 

4110 FOR 1=1 TO 6 

4115 READ MCI)> 

4120 NEXT 1 

4125 READ M$ 

4130 PRINT AT 9,01;"Vea un ''¿M$ 
4131 PAUSE 100 

4132 LET RETIRADA=0 

4134 PRINT AT 10,0;" CONSTITUCION 
">M(2): PRINT AT 10,17;"APTITUD 
25M0) 

4135 LET R=FN R(MC(1)) 

4140 LET S=FN R(C(1)) 

4145 IF S>=R THEN GO TO 4155 
4146 LET F=1: GO SUB 2500 

4147 PRINT AT 11,0;'"ARMADURA"¿M( 
5): PRINT AT 10,0;"CONSTITUCION 
"M(2)7" "2: PRINT AT 10,17;'"APT 
ITUD '"';¿MC(1): PRINT AT 11,17;'"ARM 
A" ¿US(DU+2) 

4148 IF M(2)>0 THEN GO SUB 3500 
4149 GO SUB 2500 

4150 IF RETIRADA=2 THEN LET RET 
IRADA=0: LET F=0: LET BORRARSUP= 

O: RETURN 

4155 IF C(3)>0 THEN (GO SUB 3000 
4160 IF RETIRADA=1 THEN LET F=0 
: LET RETIRADA=0: LET BORRARSUP= 


S.—Williams 
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O: RETURN 

4162 LET RETIRADA=0 

4165 IF C(3)<1 THEN GO SUB 2900 
: PRINT AT 0,0;"0h querido! Esta 
s muerto.'': PAUSE 100: LET MUERT 
0=1: LET BORRARSUP=0: RETURN 
4170 IF M(2)<1 THEN (GO SUB 2900 
: LET BORRARSUP=0: PRINT AT 0,0; 
"Le matas sin terminos inciertos 
"2 LET F=0: LET MK=MK+KM: LET TR 
=M(2)4+MC(1)+(MC(6)*FN R(3)): PRINT 
"Tenia ";¿TR;'" piezas de plata": 
PAUSE 100: LET C(7)=C(7)+TR: RE 
TURN 

4190 GO TO 4146 

4199 RETURN 

4205 GO SUB 2900 

4210 PRINT AT 0,0;"Esta en una g 
uarida de ladron" 

4215 LET N=100000: GO SUB 2800: 
LET R=FN R(10) 

4220 IF R>5 THEN PRINT "El Lladr 

on esta en'': PAUSE 100: GO TO 42 
50 

4225 PRINT "No hay nadie aqui" 
4230 IF 0<3 THEN PRINT "y ningu 

n botin ': PAUSE 100: RETURN 

4235 IF Q<6 THEN LET R=FN R (100 
): PRINT AT 0,0;'"Encuentra "'¿R;" 

piezas de plata'': LET C(7)=C(7)+ 

R: PAUSE 100: RETURN 

4240 PRINT "Encuentra una pieza 

de proteccion '": IF C(11)<9 THEN 
LET C(110=C(11)+1: PAUSE 50: R 
ETURN 

4250 LET S=FN R(100): PRINT "El 

desea ";S;'” piezas de plata" 

4252 IF<S =C(7) THEN GO TO 4270 

4255 IF>S C(7) THEN PRINT "Pero 
como usted no tiene suficiente 

el se apoderara de algo mas" 
4260 IF C(11)>0 THEN PRINT "una 
pieza de protección": PAUSE 150 
2 LET C(11)=C(11)-1: GO TO 4270 

4265 IF C(10)>0 THEN PRINT "un 

arma '': PAUSE 150: LET C(10)=C(1 

0>-1 

4270 LET C(7)=C(7)-S: IF C(7)<0 

THEN LET C(7)=0: PAUSE 100: RET 

URN 

4298 RETURN 

4299 REM TESORO 


120 


4310 LET R=FN R(5) 

4315 LET S=FN R(15) 

4316 GO SUB 2900 

4320 IF R=1 THEN PRINT AT 0,0;" 

Encuentra "¡INT (S/3)+q;5'" dardos 
magicos'': LET C(8)=C(8)+INT (S/ 

3)+1: PAUSE 150: RETURN 

4325 IF R=2 THEN PRINT AT 0,05" 

Encuentra "¿S*5;" piezas de plat 

a'': PAUSE 100: LET C(7)=C(7)+Sx* 

5: RETURN 

4330 IF R=3 THEN PRINT AT 0,0;" 

Encuentra un escudo magico'':PAUS 

E 100: LET C(11)=12: RETURN 

4335 IF R=4 THEN PRINT AT 0,0;" 

Esta rodeado por pigmeos que hu 

iran con sus armas'': LET C(10)=0 
: PAUSE 100: RETURN 

4340 PRINT AT 0,0;"Encuentra un 

monstruo de plata que devora tod 

a su proteccion": PAUSE 100: LET 
C(11)=0: RETURN 

4398 RETURN 

4399 REM POCION 

4400 PRINT 'POCION" 

4410 PRINT "Encuentra una pocion'' 

4420 PRINT "Desea tomarla (T) o 
beberla (D) o dejarla sola (L)?" 

4430 LET TS$="TDL” 

4440 GO SUB 2950 

4450 LET VENENO=FN R(2) 

4460 IF AS(1)="T" THEN LET C(9) 
=C(9)+1 

4470 IF A$(1)="D'" THEN LET C(9) 
=C(9)+1: GO SUB 5310 

4498 RETURN 

4499 REM ARMA 

4510 LET R=FN R(3): LET S=FN R(8 
+3 

4515 IF R=1 THEN LET MANDICION= 
1 


4520 LET R=FN R(3)+1 
4522 LET R=INT (S/R) 
4523 GO SUB 2900: PRINT AT 0,0;" 


4525 PRINT "Encuentra un ''+WS(R) 
4526 GO SUB 5000 

4528 IF AS(1)="N'" THEN RETURN 
4529 IF C(10)>R THEN GO SUB 290 
O: PRINT AT 0,0;"Ya tiene una me 
jor arma. Esta seguro de q 
ue la quiere?" GO SUB 5000: IF a 
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$="N' THEN RETURN 

4530 IF R=5 THEN LET C(11)=C(11 
)+2: RETURN 

4535 LET C(10)=R: RETURN 

4598 RETURN 

4599 REM ACCIDENTE 

4605 LET N=100000 

4606 GO SUB 2800 

4607 LET R=FN R(10) 

4610 IF Q<3 THEN PRINT "Una cue 

va vacia'': PAUSE 50: RETURN 

4615 IF Q<5 THEN PRINT "Cae en 

un pozo": LET C(3) = C(3)-FN R(3 
): PAUSE 100: RETURN 

4620 IF R>5 THEN GO TO 4630 

4621 PRINT "Esta cogido en una t 
rampa'': PAUSE 50: LET R=FN R(3): 
IF R =3 THEN PRINT "pero ecapa 
sin daño'": PAUSE 50: RETURN 

4622 IF R=1 THEN PRINT " y res 

ulta herido al escapar": LET C(3 
) = C(3)-FN R(5): PAUSE 100: RET 

URN 

4624 IF R=2 THEN LET S=FN R(C(1 
) x 1.5): IF<S CC(1) THEN PRINT ” 

Escapa pero queda debilitado en 
la lucha": LET C(1) = CC(1) - FN 

R(4): PAUSE 100: RETURN 

4630 IF Q<8 THEN PRINT "una gui 
llotina desciende desde arriba y 
destruye una de sus armas 

': PAUSE 100: LET C(10)=C(10)-1: 
RETURN 

4650 PRINT "Hay una cascada magi 
ca aqui. Unas pocas gotas le sal 

pican y... : PAUSE 50 

4655 LET R=FN R(3) 

4660 IF R=1 THEN PRINT "se sien 
te mucho mas fuerte'': LET STR=ST 

R+3: PAUSE 50: RETURN 

4665 IF R=2 THEN PRINT "destruy 

e su proteccion'': LET C(11) = O: 
PAUSE 50: RETURN 

4670 PRINT 'se siente mas debi 
LU": LET C(3) = C(3)-FN R(5): PAU 

SE 50: RETURN 

4698 RETURN 

4700 GO TO 4900 

4798 RETURN 

4799 REM NADA 

4800 GO TO 4900 

4900 GO SUB 2900: PRINT AT 0,0;"” 
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Encuentra una cueva vacia." 
4998 RETURN 

5000 PRINT ''Desea tomarla?"' 
5010 LET TS="YN" 

5020 GO SUB 2950 

5030 RETURN 

5100 GO TO 5111 

5110 GO SUB 2900: PRINT AT 0,0; 
5111 PRINT "Desea dejar." 

5112 PRINT "Dinero (1)" 

5113 PRINT "Un arma  (2)" 

5114 PRINT ''Un elemento magico 
(3) 

5115 PRINT "Una pocion (4)" 
5116 PRINT "Comida (5)" 

5117 PRINT "Armadura  (6)" 

5118 PRINT "Nada  (7)" 

5120 LET T$="1234567" 

5122 GO SUB 2950 

5125 GO TO 5125+(VAL  (A$)x5) 
5130 PRINT "Cuanto?" 

5132 INPUT A: IF A>CC(7) THEN P 
RINT Z$: GO SUB 2900: GO TO 5110 
5134 LET C(7)=C(7)-A: RETURN 
5135 IF C(10)<1 THEN PRINT Y$: 
GO SUB 2900: GO TO 5110 

5136 LET C(10)=C(10)-1 

5137 IF C(9)=0 THEN LET MALD 


5138 IF MALDI=1 THEN LET R=FN R 
(3): IF R=1 THEN LET MALDI=0 
5139 RETURN 

5140 IF C(8)<1 THEN PRINT YS: G 
O SUB 2900: GO TO 5110 

5142 LET C(8)=C(8)-1: RETURN 
5145 IF C(9)<0 THEN PRINT YS$: G 
O SUB 2900: GO TO 5110 

5147 LET C(9)=C(9)-1: RETURN 
5150 IF C(5)<1 THEN PRINT YS$: G 
O SUB 2900: GO TO 5110 

5152 LET C(5)=C(5)-1: RETURN 
5155 IF C(11)<1 THEN PRINT Y$: 
GO SUB 2900: GO TO 5110 

5157 LET C(11)=C(11)-1: RETURN 
5160 RETURN 

5199 REM COMER 

5200 IF C(5)<1 THEN PRINT "no p 
uede comer una piedra.'': PAUSE 2 
O: RETURN 

5210 LET C(5)=C(5)-1 

5220 LET C(3)=C(3)+INT C(FN RCC20 
-C(3))/2)) 
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5298 RETURN 
5299 REM POCION 
5305 GO SUB 2900: PRINT AT 0,0;" 


5310 IF C(9)<1 THEN PRINT "No t 
jenes ninguna pocion'': RETURN 
5320 LET C(9)=C(9)-1 

5330 IF VENENO=1 THEN LET P=FN 
RG) 

5340 LET R=FN R(6): LET S=FN RC(4 


) 

5345 IF P=1 THEN LET VENENO=0: 
GO TO 5370 

5360 GO SUB 2900: PRINT AT 0,0;" 
Su "C$(S);'"sube '"¿R=" puntos "': 
LET C(S)=C(S)+R: RETURN 

5370 GO SUB 2900: PRINT AT 0,0;" 
Grita!!! Se enveneno ! Su "'C$(S 
);" disminuye "¿R+1;'" puntos'': L 
ET C(S)=C(S)-R 

5398 RETURN 

5399 REM reposo 

5410 LET CONTADOR=1 

5420 LET R=FN R(5) 

5430 IF R=1 THEN GO SUB 2900: P 
RINT AT 0,0;"Su respiracion ruid 
osa atrae a un monstruo'"';: PAUSE 
100: GO SUB 4100 

5440 RETURN 

5499 REM Antorcha 

5510 IF ANTORCHA<O.1 THEN PRINT 
YS$: RETURN 

5220 LET ANTORCHA=ANTORCHA-0. 1 
5330 LET INDACTORC=1 

5540 GO SUB 1045 

8998 RETURN 

7999 REM ESTABLECIMIENTO DE VARI 
ABLES FUNCIONES Y ARRAYS 

8000 RANDOMIZE 

8001 LET CAIDA=0: LET MK=0 

8002 LET KM=0: LET BORRASUP=0 
8003 LET MALDI=0 

8004 LET F=0 

8005 LET MOV=0 

8006 LET INDANTORC=0 

8007 LET ANTORCHA=0 

8008 LET VENENO=0 

8009 LET MUERTO=0 

8010 DEF FN P()= SQR (X*X+Y*YxZ) 
- INT (SQR (X*X+Y*YxZ)) 

8011 LET PUNTO=0 

8012 LET TURNO=0 
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8015 LET H$="Cuantos" 

8020 DEF FN R(x)=INT (RNDxx) +1 

8022 LET X=FN R(10)+10: LET Y=FN 
R(20)+10: LET Z=1 

8025 LET Z$="N0 tiene suficiente 


8030 LET Y$="No0 tiene ninguno" 
8031 DIM U$(3,7) 

8032 LET U$(1)="ARRIBA" 

8033 LET U$(3)="'ADELANTE" 
8035 DIM W$(5,6) 

8036 DIM B$(5,12) 

8037 LET DA=0: LET AD=0 

8038 LET AU=0: LET DU=0 

8039 LET AF=0: LET DF=0 

8040 DIM C$(12,12) 

8045 DIM C(12) 

8046 DIM M(6) 

8047 LET M$="" 

8048 LET RETIRADA=0 

8050 LET J$='"Desea tomarlo?" 
8055 LET CONTADOR=0: LET FATIGA= 
O: LET LUCHA=0: LET MAGICO=0 
8060 FOR I=1 TO 12 

8065 READ CS$(1) 

8070 LET CC(1I)=0 

8075 NEXT 1 

8080 FOR 1=1 TO 5 

8085 READ W$(1) 

8090 NEXT 1 

8100 FOR I=1 TO 5 

8105 READ B$(1) 

8110 NEXT 1 

8195 CLS 

8199 REM Establecimiento caracte 


r 

8200 PRINT "Tiene 12 puntos para 
distribuir entre fortaleza,aptit 
ud, constitucion y conocimiento 
” 


8205 LET C(4)=12 

8206 LET C(7)=100 

8210 PRINT H$;' Fortaleza" 

8220 INPUT C(1) 

8225 IF C(1)>C(4) THEN PRINT Z$ 
: LET C(1)=0: GO TO 8210 

8226 LET C(4)=C(4)-C(1) 

8227 LET C(1)=C(1)+8 

8230 PRINT H$;" Aptitud" 

8240 INPUT C(2) 

8245 IF C(2)>C(4) THEN PRINT Z$ 
: LET C(2)=0: GO TO 8230 
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8246 LET C(4)=C(4)-C(2) 
8247 LET C(2)=C(2)+8 
8250 PRINT H$;' Constitucion" 
8260 INPUT C(3) 
8265 IF C(3)>C(4) THEN PRINT Z5$ 
: LET C(3)=0: GO TO 8250 
8266 LET C(4)=C(4)-C(3) 
8267 LET C(3)=C(3)+8 
8270 PRINT 'Que deja ";C(4);" p 
ara conocimiento" 
8275 LET C(4)=C(4)+8 
8299 REM ESTABLECIMIENTO VISUALI 
ZACION 
8300 FOR I=1 TO 6 
8310 PRINT AT 15+1,0;C$(1) 
8320 PRINT AT 15+1,16;C$(1+6) 
8330 NEXT 1 
8335 PRINT AT 15,0;'"ANTORCHAS "': 
PRINT AT 15,16;''PUNTOS " 
8340 GO SUB 2510 
8399 REM Compra 
8400 GO SUB 2500: GO SUB 2900 
8402 IF C(7)<8 THEN GO SUB 2900 
: PRINT AT 0,0;"No tiene suficie 
nte dinero '': RETURN 
8405 PRINT AT 0,0;" "; 
8410 PRINT "Tiene ld ¿C7; " pieza 
s de plata" 
8415 PRINT "puede comprar :'' 
8420 PRINT "ITEM 

SP cada uno" 
8425 PRINT ''(A) Armadura (por pi 
eza) 15" 
8430 PRINT ''(F) Paquete conida 


8435 PRINT "(K) Cuchillo 

8440 PRINT ''(M) Dardo magico 
8445 PRINT '"(P) Pocion 

8450 PRINT '(S) Espada 

8455 PRINT "(W) Antorcha 

8460 PRINT ''(2) Final compra" 
8465 LET TS="AFKMPSWZ'': GO SUB 2 
950 

8470 GO TO 8406+C0DE AS 

8471 IF CC(7)<15 THEN PRINT Z5$: 
GO SUB 2900: GO TO 8400 

8472 LET C(11)=C(11)+1: LET CC7) 
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=C(7)-15: GO TO 8400 

8476 1F C(7)<10 THEN PRINT Z5$: 
GO SUB 2900: GO TO 8400 

8477 LET C(5)=C(5)+1: LET C(7)=C 
(73-10: 60 TO 8400 

8481 IF C(7)<10 THEN PRINT Z$: 
GO SUB 2900: GO TO 8400 

8482 LET C(10)=1: LET C(7)=CC(7)- 
10: GO TO 8400 

8483 IF C(7)<25 THEN PRINT Z$: 
GO SUB 2900: GO TO 8400 

8484 LET C(8)=C(8)+1: LET C(7)=C 
(7)-25: GO TO 8400 

8486 IF C(7)<30 THEN PRINT Z$: 
GO SUB 2900: GO TO 8400 

8487 LET C(9)=C(9)+1: LET C(7)=C 
(73-30: G0 TO 8400 

8489 IF C(7)<30 THEN PRINT Z$: 
GO SUB 2900: GO TO 8400 

8490 LET C(10)=2: LET C(7)=C(7)- 
30: GO TO 8400 

8493 IF C(7)<8 THEN PRINT Z5$: G 
O SUB 2900: GO TO 8400 

8494 LET ANTORCHA=ANTORCHA+1: LE 
T C(7)=C(7)-8: GO TO 8400 

8496 RETURN 

8498 RETURN 

8499 REM INSTRUCCIONES 

8500 PRINT AT 10,8; FLASH 1;'"'MIN 
AS DE MERLIN” 

8505 PAUSE 500: CLS 

8510 PRINT " Este es un recint 
o aleatorio que contiene element 
os magicos y de combate. El obje 
tivo es obtener tantos puntos co 
mo sea posible 

8520 PRINT AT 6,4;"Ello se hace 
buscando tesoros y abatiendo mon 
struos.'” 

8530 PRINT AT 9,0;"Pero debe aut 
ocontrolarse. Si su constitucion 
se hace inferior a 1, estara mue 
rto." 

8540 PRINT AT 13,0;"Perdera cons 
titucion ",'"si olvida reposar, o 
se esta herido,",,,. La 
constitucion y la fortaleza"," d 
eterminan cuanto puede transport 
ar'";"la aptitud y la fortaleza a 
yudan en el combate,”,"la aptitu 
d y el conocimiento determinan", 
ha el combate magico." 
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8550 PRINT  0;"Pulse cualquier t 
ecla para continuar" 

8555 PAUSE 1000 

8559 CLS 

8560 PRINT ' La comida aumenta 
La constitucion" 

8570 PRINT AT 3,2;"Las pociones 
pueden aumentar sus'”','"'  capacid 
ades, pero pueden estar'"',"' 
envenenadas."' 

8580 PRINT AT 7,2;'"Comienzo con 
ocho puntos",''para cada una de 
sus capacidades y"," tiene do 
ce puntos para"," distribuir." 
8600 PRINT  0;"Pulsar cualquier 
tecla para continuar" 

8610 PAUSE 1000 

8620 CLS : PRINT AT 10,8;"INICIA 
LIZACION” 

8998 RETURN 

8999 REM DATOS 

9010 DATA "Fortaleza",'aptitud”, 
"constitucion”,'conocimiento”,''c 
omida”*,''carga max" ,'"dinero",'dar 
dos magicos','pociones'",'valor a 
rma",'"valor proteccion",'"carga"' 
9020 DATA "CUCHILLO ',''ESPADA ", 
"MAYAL ","LANZA ","ESCUDO "," 
9030 DATA ''Comida ','Una espada" 
, Una pocion ",'"Un dardo magico"' 
7 Antorchas" 

9201 DATA "un gitano" 

9202 DATA "un monstruo"' 

9203 DATA "guarida de ladron" 
9204 DATA "un tesoro" 

9205 DATA "una pocion" 

9206 DATA "un arma" 

9207 DATA "un riesgo" 

9208 DATA "nada" 

9209 DATA "nada" 

9210 DATA "nada" 

9250 DATA 7,15,3,4,14,2,'serpien 


9251 DATA 12,8,2,3,16,4,'"demonio 
9252 DATA 9,13,5,6,9,5,'"duende"' 
9253 DATA 8,16,6,5,9,8,'svart" 

9254 DATA 13,8,3,2,10,4,'grendel 
9255 DATA 16,6,8,4,12,3,'La Parc 


9256 DATA 14,4,5,1,13,6,"ogro" 


9257 DATA 16,10,4,2,11,6,''zombie 


9258 DATA 14,12,5,3,16,3,'"profan 
ador de tumbas"' 
9259 DATA 10,11,6,3,13,7,'"'gigant 


9260 DATA 12,16,6,4,12,5,'"fantas 
9261 DATA 18,10,2,3,14,5,"vampir 


9262 DATA 16,9,3,2,14,8, dragon" 
9263 DATA 14,14,5,3,12,9,'presag 
iador de muertes"' 

9264 DATA 17,11,8,3,14,7,''hado"" 

9265 DATA 10,15,2,2,10,'"devorado 
pa 

9266 DATA 18,12,6,6,14,8,''sangul 
juelas"” 

9267 DATA 17,14,2,2,15,9,''hombre 
Lobo"' 

9268 DATA 18,16,2,2,12,10,'"demon 
10 de patas de cabra"' 

9269 DATA 19,15,2,8,14,9,"Belceb 
u” 


9900 PRINT "FINAL": STOP 
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7 TEXTO 


7.1 Entrada 


La clase de entrada que utiliza un juego de aventuras depende, en alguna 
medida de su tipo. Por ejemplo, una aventura de gráficos en tiempo real 
necesita una entrada de tecla única, mientras que una aventura de enigma 
completa exige una entrada que sea lo más próxima posible al lenguaje 
inglés ordinario. Hay otras clases de entrada, pero examinaremos sola- 
mente estas dos, utilizando la segunda para el juego de enigmas de 
Camelot y la primera para las Minas de Merlín. En ambos casos, el 
procedimiento es el mismo: 


1. INDICAR QUE ENTRADA SE NECESITA 

2. EL JUGADOR INTRODUCE LA INFORMACION 

3. COMPROBAR QUE LA INFORMACION ES ACEPTABLE 
4. INTERPRETAR LA ENTRADA 

5. ACTUAR SOBRE LA ENTRADA 


La entrada de tecla única es la más fácil de programar y, en algunas 
formas, la más fácil para el jugador si solamente existen unas pocas 
entradas posibles. Sin embargo, si se requieren demasiadas teclas (más de 
8), el jugador olvidará la función de cada una y cometerá errores. Aunque 
ello pueda ser de utilidad en algunos juegos, a la mayoría de los jugadores 
no les complacerá un juego que esté esencialmente concebido para probar 
su conocimiento del teclado. 

Para la entrada de tecla única, los números son más fáciles de procesar, 
sobre todo porque la entrada numérica es más sencilla de comprobar. Por 
ejemplo, si los números 2 a 6 son la única entrada admitida, una rutina tal 
como la siguiente realizará la operación correspondiente: 


90 PRINT “Sírvase teclear un número entre 2 y 6 y pulse ENTER” 
100 INPUT A 

110 LETA = INTA 

120 IFA A>6 OR A<2 THEN GOTO 90 


La línea 110 es necesaria para cerciorarse de que los jugadores no 
intentarán la introducción de una entrada con dígitos decimales. 

Como cada tecla en el teclado tiene un código, podemos definir una 
gama de teclas admisibles en la misma forma. Los códigos para todos los 
caracteres del Spectrum están contenidos en el Apéndice A del Manual. 
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Por ejemplo, las letras minúsculas a a f tienen los códigos 97 a 102 
inclusive. Para comprobar esta entrada, tendríamos que cambiar la rutina 
anterior por la siguiente: 


90 PRINT “Sírvase teclear una letra de a a f y pulse ENTER” 

100 INPUT AS 

110 LET AS=A$(1): REM SOLAMENTE EN EL CASO DE QUE 
SE TECLEE MAS DE UNA LETRA 

120 IF CODE A$<97 OR CODE A$> 102 THEN GOTO 90 


El problema se plantea por el hecho de que las teclas que elijamos no 
es probable que sean fáciles de recordar a menos que la primera letra del 
significado de la orden, tal como las letras habituales N, S, E, W para los 
puntos cardinales. La comprobación de los errores en una entrada tan 
compleja como éstas, puede ser bastante complicada en sí misma. 

Por muy bien concebido que esté nuestro programa siempre existirá 
alguna posibilidad de que tengamos entradas que no estén permitidas y, 
por consiguiente, el jugador, siempre podrá cometer el error correspon- 
diente. Por tanto, nuestro procedimiento de comprobación de errores no 
solamente ha de cerciorarse de que la entrada está dentro del margen 
correcto, sino que también ha de ser sensible a otros posibles errores. 
Cada vez que el jugador pulse una tecla, debe existir una rutina adecuada 
para detectar cualquier posible error. Esta “trampa” de errores debe estar 
lo antes posible en la rutina si es probable que exista un error, pero puede 
estar al final si los errores son menos probables. Si existiera incertidum- 
bre, la comprobación debe ir inmediatamente después de la sentencia 
INPUT (o GET o INKEY). 

Si se detectara un error, alguna forma de mensaje de error debe 
enviarse al jugador para informarle de tal circunstancia. Los mejores 
mensajes de error comunican al jugador tres cosas: 


1. Que ha cometido un error. 
2. La clase de error que ha cometido. 
3. La clase de entrada que es admisible. 


La clase más desfavorable de mensaje de error es que no exista ningún 
mensaje (!). El jugador no tendrá ninguna idea de lo que va a suceder o de 
lo que está haciendo. 

Si vamos a permitir varias entradas diferentes de tecla única, todo lo 
que podemos hacer para su comprobación es probarlas una a una. Esta 
operación la podríamos hacer de forma mecánica utilizando una sentencia 
IF... THEN para cada una de las posibles entradas cada vez que se 
requiera una de ellas, siendo “ERROR” la línea por defecto, pero ello 
tiene los defectos habituales de falta de elegancia, desperdicio de capacidad 
y poca eficacia. 

Lo que precisamos es una rutina para comprobar que la letra de la 
entrada es una incluida en un conjunto de caracteres aceptables. Es 
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bastante probable que en diferentes puntos en el juego se permitirá 
conjuntos de caracteres diferentes. Por ejemplo, durante el combate las 
posibilidades podrían ser: 


A = ATAQUE 
M = MAGICO 
R = RETIRADA 


mientras que al introducir una nueva posición, las opciones podrían ser: 


O = OIR 

R = REPOSAR 
B = BUSCAR 
E = ESPERAR 


Por consiguiente, la rutina debe ser de tipo general que pueda ser objeto de 
llamada siempre que se espere una entrada de letra única para la 
comprobación de su validez. 

El método que consideramos más adecuado es mantener los caracteres 
válidos como una cadena y comparar el carácter de entrada con cada uno 
de los incluidos en la cadena de forma sucesiva. Llamaremos a la cadena 
TS (por Test). A continuación, cada vez que se espere una entrada de letra 
única utilizaremos INKEYS$ en lugar de INPUT, para aprovechar al 
máximo la ventaja principal de la entrada de letra única, que es la 
velocidad, utilizando la rutina siguiente: 


80 REM PARA ENTRADA DE COMBATE 
90 PRINT “Sirvase teclear una letra única (A,M o R)” 
100 LET TS = “AMRamr”*:.REM DECLARAR CADENA DE 
PRUEBA 
110 GOSUB 1000 
120 PRINT “O.K. Es válida” 
900 STOP 
999 REM COMPRUEBA CARACTERES VALIDOS 
1000 LET A$ = INKEYS 
1010 LETT =0 
1020 IF AS = “” THEN GOTO 1000 
1030 FOR I = 1 TO LEN (TS) 
1040 IF TS() = AS THEN LET T = 1 
1050 NEXT I 
1060 IF T = 1 THEN RETURN 
1070 PRINT “No, no seas necio, introduce A, M o R” 
1070 GOTO 1000 


Si examina detenidamente esta rutina observará que el control sola- 
mente retorna desde la subrutina si se pulsa una de las teclas correctas. T 
se pone a “1” solamente si se encuentra una de las teclas correctas y el 
control solamente vuelve a la rutina principal si T se ha puesto a 1. 
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La subrutina 1000 puede ser objeto de llamada en cualquier momento 
durante el juego, en tanto que recordemos efectuar la declaración en la 
cadena de prueba antes de que se efectúe la llamada correspondiente. 
Obsérvese que la cadena declarada controla la subrutina por su contenido 
y por su longitud. Es importante que no incluyamos ningún carácter no 
válido en la cadena, tal como signos de puntuación o espacios, a no ser 
que éstos últimos sean entradas válidas posibles. 

Asimismo, ha de tenerse presente que cuanto más larga es la cadena T$ 
tanto más larga será la ejecución de rutina, por lo que es preferible 
mantener a T$ limitada a 5 Ó 6 caracteres en cada caso. 

Este método de comprobación se utiliza en las Minas de Merlín, con la 
rutina correspondiente situada en las líneas 2950 a 2998. Ha de observarse 
dos perfeccionamientos en este caso. La línea 2960 convierte cualquier 
entrada en letras minúsculas en otra en letras mayúsculas, con lo que se 
consigue que las cadenas de prueba sean mucho más cortas y más fáciles 
de codificar. La línea 2964 indica al jugador qué carácter acaba de teclear, 
de modo que pueda observar cualquier error cometido. Una de las 
características más desfavorables del personaje del jugador es la forma en 
que inculpa al programa de la manera en que sus dedos se deslizan por el 
teclado. 

Si utilizamos una entrada de tecla única, hemos de intentar hacer lo 
siguiente: 


l. Elegir solamente unas pocas teclas. 

2. Elegir teclas cuyo significado tenga una correspondencia fácil de 
recordar con la orden correspondiente. 

3. Cerciorarse de que podemos comprobar los posibles errores en la 
entrada. 

4. Elegir una combinación de teclas que se pueda manipular fácilmente en 
el teclado, sobre todo si el juego es en tiempo real. 


¿Qué se puede decir acerca de las entradas “idiomáticas”? Es habitual 
en las aventuras basadas en texto que se permitan órdenes con parejas de 
palabras, tal como “GO WEST” (“VAYA AL OESTE”), “TAKE 
BOOK” (“COJE LIBRO”), etc. Por supuesto, estas entradas son más 
complejas que las de tecla única; llevan más tiempo para su diseño, 
codificación y empleo en la ejecución del juego, pero ofrecen compensacio- 
nes mucho más variadas que la entrada de tecla única limitada. 

Incluso con esta complejidad, se puede utilizar una técnica similar a la 
de comprobación de la entrada de tecla única. Las diferencias son que ha 
de utilizarse INPUT en lugar de INKEYS$ (por lo que la tecla ENTER ha 
de pulsarse después de cada entrada por el jugador) y que la cadena que se 
introduce ha de dividirse en sus palabras separadas. Supondremos una 
entrada de dos palabras, aunque los principios siguen siendo los mismos 
para frase o sentencias más largas. En Camelot solamente se permitirá 
una entrada de dos palabras, aunque más adelante examinaremos algunas 
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formas en que tal circunstancia se podría modificar. Necesitamos declarar 
algunas variables de cadena de las que haremos uso, tales como las que se 
indican a continuación. 


A$ es la entrada de cadena por el jugador 

BS es la primera palabra 

C$ es la segunda palabra 

D$ es la que corresponde a las tres primeras letras de la primera 
palabra 

ES es la que corresponde a las tres primeras letras de la segunda 
palabra 

N$ es una cadena de prueba para nombres 

V$ es una cadena de pruebas para verbos. 


Ahora se hará más evidente la necesidad de todas ellas. Sería preferible 
que pudiéramos utilizar nombres de variables con más títulos nemónicos 
(para facilitar su recordatorio en la escritura y depuración del programa) 
pero el Spectrum BASIC solamente permite nombres de una sola letra 
para las variables de cadena. El diagrama de flujo que utilizaremos es: 


1. EL JUGADOR INTRODUCE UNA ORDEN DE DOS PALABRAS 

2. LAS PALABRAS SE SEPARAN 

3. DS SE ESTABLECE PARA LAS TRES PRIMERAS LETRAS DE LA 
PRIMERA PALABRA 

4. D$ SE COMPRUEBA CON RESPECTO A V$ 

5. E$ SE ESTABLECE PARA LAS TRES PRIMERAS LETRAS DE LA 
SEGUNDA PALABRA 

6. ES SE COMPRUEBA CON RESPECTO A N$ 


Aunque podríamos comprobar las palabras completas que se introdu- 
jeron, ello llevaría más tiempo y memoria que lo que se estima necesario. 
Un código de tres letras es suficiente para distinguir muchas palabras y, 
con tal de que podamos asegurar que ninguna pareja de palabras de 
órdenes válidas en nuestro programa comience con las mismas tres letras, 
no se planteará ningún problema. Por consiguiente, no ha de elegirse 
CANDELABRO y CANIBAL, por ejemplo, en el mismo programa. Si, 
por algún motivo, ha de tomar palabras clave que comiencen con las 
mismas tres letras, tendrá que utilizar códigos de cuatro letras, o más, si 
han de distinguirse dichas palabras, pero ello debe evitarse en la medida de 
lo posible. 

En el programa del Trono de Camelot se utilizan entradas de dos 
palabras. Entre sus Órdenes permitidas están: ENCENDERANTORCHA, 
TOMARRUEDA y NADARRIO. Los verbos permitidos son, pues, 
ENCENDER, TOMAR y NADAR, mientras que los nombres permitidos 
son: ANTORCHA, RUEDA y RIO. Obsérvese que ninguna pareja de 
estas palabras comienzan con las mismas tres letras. Podemos compilar 
cadenas constituidas por los códigos de tres letras de palabras aceptables 
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en la misma forma que hicimos para T$ en la anterior rutina de entrada de 
tecla única. De este modo, en algún lugar del programa habrá una línea en 
la que se diga LET V$ = “ENCTOMNAD”. 

A continuación, podemos comparar las tres primeras letras de nuestras 
palabras de entrada (D$ y E$) con cada sección de tres letras de esta 
cadena y, si hay coincidencia, podremos bifurcar a la rutina correspon- 
diente. Examinaremos el procedimiento total etapa a etapa en el Spectrum 
BASIC. Habida cuenta de que precisaremos de esta rutina con bastante 
frecuencia, se debe insertar en nuestro programa en las líneas 1000 a 1500. 

En primer lugar, ha de introducirse las palabras: 


999 REM ENTRADA DE DOS PALABRAS 
1000 PRINT “Qué sigue?” 
1010 INPUT A$ 


A continuación ha de separarse A$ en dos palabras: 


1020 LET"K. =0: LET BS$="": LET E$=*. LET. D$="": LET 
ES=*“” 

1030 FOR I = 1 TO LEN (AS) 

1040 IF ASO)=“ ” THEN LET B$ = AS(1 TO I— 1): LET C$ = 
AS(I+1 TO LEN (AS)); LET K = K+1 

1050 NEXT I 

1060 IF K<>1 OR C$ = “” THEN PRINT “Dos palabras por 
favor”; GOTO 1000 


K es un contador que indica el número de espacios encontrados, por lo 
que la línea 1050 puede comprobar que solamente hay un espacio y que se 
han encontrado dos palabras. 

A continuación, tomaremos las tres primeras letras de cada una de las 
dos palabras. Ahora, el problema radica en las palabras tales como GO 
que tienen solamente dos letras. Tendremos que añadir un espacio a 
dichas letras, lo que significa que V$ debe incluir a GO más un espacio si 
se trata de una orden permitida; v.g., “ENCPOMGO NAD”. La línea 
1060 quedará de la forma siguiente: 


1060 LET B$ = B$ + “ ”: LET C$ = C$ + 
1070 LET D$ = BS(1 TO 3): LET E$ = C$(1 TO 3) 
1075 LET FL = 0 


6» 


De forma análoga, podemos utilizar una cadena tal como “N S E W” 
para definir las órdenes de movimientos que se pueden introducir como 
órdenes de letra única pero que no se confundirán con las letras iniciales 
de otras palabras. 

A continuación, comprobamos DS con los códigos de verbos (VS) y ES 
con respecto a los códigos de nombres (N$). Habida cuenta de que el 
proceso es el mismo para ambos, podemos utilizar la misma rutina de 
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comprobación por dos veces, con tal de que hagamos la declaración de las 
cadenas correspondientes antes de efectuar la llamada: 


1080 LET T$ = V$: LET U$ = D$: GOSUB 1200 

1085 IF FL = 1 THEN RETURN 

1090 LET TS = N$: LET US$ = E$: GOSUB 1200 

1095 IF FL=1 THEN RETURN 

1096 PRINT “O.K.” 

1099 RETURN 

1199 REM RUTINA PARA COMPARAR CADENA DE PRUEBA 
Y PALABRA DE ENTRADA 

1200 FOR [ = 1 TO LEN(TS) STEP 3 

1210 IF TS(A TO I+2) = US THEN RETURN 

1220 NEXT I 

1230 PRINT “No se como hacer”; AS: LET FL = 1 

1240 RETURN 


Obsérvese que el indicador FL se establece en las líneas 1075 y 1230. 
En la línea 1075 se le pone a cero, en caso de que se le haya utilizado ya. 
En la línea 1230 se le pone a 1 si la primera mitad de la orden no es válida 
de modo que, al volver a 1085, la rutina no se ejecute en la segunda parte. 
Obsérvese también la orden STEP en la línea 1200, que puede ser una 
instrucción que no haya utilizado con anterioridad: Ello significa simple- 
mente que el bucle FOR... NEXT entre las líneas 1200 y 1220 incrementa- 
rá a Y en tres cada vez, con lo que se desplaza a lo largo de T$ tres 
caracteres cada vez, que es como están agrupados nuestros códigos. En 
condiciones normales, un bucle FOR...NEXT actuará en pasos de “1”, 
que es el valor por defecto si no se especifica en STEP. 

Una vez que se haya comprobado que la entrada es correcta, tendre- 
mos que bifurcar a la rutina adecuada en el programa. La forma más 
elegante de hacer esta operación sería utilizar una entrada numérica o 
códigos de caracteres como la base del envío del control a las subrutinas. 
Por ejemplo, una rutina de entrada y de selección muy elegante sería: 


90 PRINT “Sírvase teclear una instrucción de l a 9” 

100 INPUT A: LET A = INT(A): IF A<1 OR A>9 THEN GOTO 
100 

110 GOSUB A = 1000 


Esta rutina envía el control a las subrutinas que comienzan en las líneas 
1000, 2000, hasta 9000. Sin embargo, dicha elegancia no es siempre 
posible si la entrada es de letras iniciales o de palabras completas. 
Mediante un diseño cuidadoso, podríamos enviar el control a una 
subrutina relacionada con el código (CODE) de caracteres o la suma de 
los códigos en cualquier combinación de tres letras pero probablemente no 
merezca la pena el esfuerzo del diseño correspondiente. En consecuencia, 
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una serie de pruebas de una sola línea se utiliza para dirigir el control a las 
rutinas adecuadas y su forma es: 


IF entrada = palabra clave x THEN GOSUB rutina y 
Para nuestro ejemplo de tecla única, las líneas adecuadas podrían ser: 


130 IF AS = “A” THEN GOSUB 2000 
140 IF A$ = “M” THEN GOSUB 2100 
150 IF AS = “R” THEN GOSUB 2200 


y para la entrada de dos palabras, las lineas apropiadas podrian ser: 


130 IF BS = “TOM” THEN GOSUB 2000 
140 IF B5$ = “NAD” THEN GOSUB 2100 
etc. 


Sin embargo, el Spectrum BASIC lo hace mejor facilitando algo las 
cosas. El parámetro de un GOSUB o de un GOTO puede ser una variable 
numérica y las variables numéricas pueden tener cualquier número de 
caracteres. En consecuencia, cada código de tres letras o letra aceptable 
puede utilizarse como un nombre de variable, y el valor de la variable se 
puede declarar como el número de línea de la subrutina correspondiente. 

Para aclarar lo anterior, utilicemos el ejemplo de NADAR. Suponga- 
mos que la rutina de natación comienza en la línea 2210. Durante la 
inicialización del programa, podemos asignar un valor a la variable 
llamada NAD, que también resulta ser nuestro código de tres letras para 
nadar. Cuando la entrada haya pasado a través de todas las comprobacio- 
nes de validación, B$ tendrá a “NAD” como la primera parte de la 
primera palabra. Si podemos transformar la cadena mantenida por B$ en 
el valor contenido por la variable con el mismo nombre, podremos utilizar 
la cadena de entrada para dirigir el control. 

La función que realiza esta tarea es VAL, que convierte una cadena en 
su valor correspondiente. Si nuestro programa contiene, entre otras, las 
líneas siguientes: 


10 LET NAD = 2110 


Entonces, actuará si “NADAR” es la primera entrada de palabra. 

La ventaja de este procedimiento es que resulta más fácil seguir las 
operaciones del programa y, al mismo tiempo, ahorra codificación. 
necesitamos una orden LET para cada palabra de entrada aceptable, pero 


137 


podemos prescindir de todas las sentencias IF...THEN interminables. 
Asimismo, permite a los programadores inteligentes modificar la rutina 
que una orden particular está ejecutando. Por ejemplo, pueden existir dos 
posiciones en las que se podría permitir a un jugador nadar, por ejemplo, 
a través de una corriente tranquila y un río peligroso. Si el jugador trata 
de atravesar a nado la corriente tranquila, no hay ningún peligro de 
ahogamiento. En el caso de río peligroso, todo es idéntico al caso de la 
corriente tranquila, con la salvedad de que existe el peligro de ahogamien- 
to. Por consiguiente, la misma rutina se utilizará para cada uno de estos 
casos, con un elemento de codificación suplementario para el río. Si este 
elemento adicional se mantuvo en la línea 2005, con la rutina común en 
2110, entonces, una línea como la que se indica a continuación podría 
hacer uso de dicho elemento de codificación: 


135 IF POSICION = RIO THEN LET NAD = 2005 


Sin embargo, este artificio solamente es de utilidad en pocas circunstan- 
cias, puesto que el código suplementario se puede retener y llamar en otras 
formas; v.g., mediante el empleo de indicadores o de subrutinas anidadas. 

Como los nombres que se utilizan con más frecuencia serán los 
relativos a los movimientos, podemos acelerar el proceso teniendo dos 
cadenas de nombres, una llena de objetos y la otra para direcciones (por 
ejemplo, “NORSURESTOES” y solamente probar la última cuando se 
detecte un verbo de movimiento válido (esto es, en el caso de Camelot 
GO). Además, necesitaremos dos órdenes especiales que no necesitan 
nombres; a saber, AYUDA e INVENTARIO. 

La primera de estas dos órdenes proporciona ayuda al jugador ante 
problemas; la segunda proporciona un listado de todos los objetos de los 
que dispone actualmente. Antes de la rutina de comparación de palabras 
normal, necesitamos tres pruebas separadas para estos tres verbos. Puesto 
que las dos últimas no tienen ningún nombre, las probaremos antes de la 
rutina principal; esto es, entre las líneas 1015 y 1020: 


1016 IF AS(1 TO 3) = “INV” THEN GOSUB INV: RETURN 
1017 IF AS(1 TO 3) = “AYU” THEN GOSUB AYU: RETURN 


La prueba para GO irá antes de las pruebas de los verbos y de los 
nombres principales; esto es, antes de 1080. Si W$ es la cadena “NORSU- 
RESTOES”, las líneas 1078 y 1079 realizarán la tarea: 


1078 1F DS = “GO” THEN LET TS = WS: LET U$ = E$: GOSUB 
1200: IF FL = 1 THEN RETURN 
1079 IF D$ = “GO” THEN GOSUB VAL(B$): RETURN 


Estas líneas realizan la comprobación de que la palabra que sigue a GO es 
una dirección legítima, envían el control de nuevo al programa principal si 
no fuera así O avanzan a la rutina GO si así lo fuera. 

Asimismo, tenemos que hacer minimos los efectos de la introducción 
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defectuosa de las Órdenes. Análogamente a los errores traen consigo la 
introducción por el teclado de una sola palabra, o palabras de menos de 
tres letras o espacios adicionales. Puesto que la rutina de comprobación 
utiliza el dispositivo de fragmentación de cadenas, estas anomalías 
podrían dar lugar al número de error 3, que corresponde al subíndice 
equivocado, por ejemplo, porque la cadena no es suficientemente larga 
para ser troceada. Una forma fácil de evitar la mayoría de estos problemas 
es declarar las variables no como cadenas vacías, sino como cadenas de 
espacios y borrar cada cadena en el número requerido de espacios cada vez 
que se utilice el bucle de entrada. Esta operación se realiza en las líneas 
1000 y 1011 del programa. 

Una vez que se haya ejecutado el bucle, proporcionará un indicador 
que señale si se ha producido un error y se volverá a repetir la entrada. Sin 
embargo, si ambas palabras de entrada son correctas, el control tendrá 
que pasar a otras rutinas en el programa. En el caso de Camelot, las 
rutinas son de movimiento (bloque 3) o de descripción (bloque 4 y 5). Para 
que los nombres y verbos detectados se puedan utilizar en dicho control se 
le han de asignar valores numéricos y si no deseamos utilizar el método 
expuesto de declarar variables con los mismos nombres que los códigos de 
verbos y valores iguales a los números de línea de la subrutina tendremos 
una nueva alternativa. 

Para cada verbo o nombre ya tenemos un valor, que es la posición del 
código de tres letras para cada palabra en la cadena correspondiente. Ello 
es objeto de conteo por la variable Y en el bucle que intenta la 
coincidencia de D$ o ES con respecto a estos códigos, pero Y se utiliza 
como la variable en otros diversos bucles, por lo que el control podría 
hacerse algo confuso. En consecuencia, hay una orden en la línea 1210 que 
hace tomar a K el mismo valor que Í si se encuentra una coincidencia en el 
bucle de comprobación. A continuación, K se vuelve a pasar a la rutina de 
comprobación principal en donde se convierte en la variable correspon- 
diente, en este caso denominada VERBO o NOMBRE. 

Si hubiera que detectarse palabras especiales, en VERBO y NOMBRE 
tendrían que establecerse de forma especial. En el juego de Camelot, hay 
dos palabras de esta naturaleza, INVENTARIO y AYUDA, que se 
consideran como casos especiales ante el comprobador general. Para estas 
palabras, el VERBO ha de establecerse de forma especial. 

Con estas dos variables, VERBO y NOMBRE, pueden ser objeto de 
llamada la mayor parte de las rutinas descriptivas. VERBO se utiliza 
como la variable de control para llamar a las rutinas de verbos adecuadas 
y NOMBRE se emplea como una de las variables que determina la 
subrutina exacta que se utiliza. 

Puesto que estos valores son de tipo crucial, es muy importante 
enfocarles desde un punto de vista lógico. Mientras estuve realizando la 
codificación de mis aventuras, utilicé tres hojas de referencia principales 
para encontrar mi camino a través del programa. Estas últimas son 
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todavía más importantes si no dispone de ninguna impresora que le pueda 
proporcionar una salida impresa de las zonas problemáticas o no acaba- 
das de su programa. 

Mi primera hoja de referencia es un mapa del laberinto lógico con cada 
posición numerada tal como se indica en el Capítulo 6. Cada posición, que 
es un cuadrado GET o NEED, tiene una letra G o N escrita en el mismo, 
junto con los nombres que estén allí. Además, cualquier característica o 
enigma especial se indican también en esa posición, tal como el río que ha 
de atravesarse a nado. Finalmente una letra H se coloca en cada cuadrado, 
en donde está oculto un objeto, en vez de que sea inmediatamente obvio. 

Para facilitar las cosas, utilicé la variable POSICION en el programa 
para mantener el código PEEK para cada posición en el mapa y ésta es la 
variable de control para las rutinas de descripción en el bloque 6 (líneas 
6000 a 6999). La correspondencia es la siguiente: El número de posición 
está indicado en el mapa dibujado a mano, se mantiene por encima del 
Ramtop en una dirección específica y cuando se multiplica por 10 y se 
suma a 6000 nos da el número de la rutina de descripción. 

La segunda lista es la de todas las rutinas de verbos y sus líneas de 
comienzo. Estas deben estar espaciadas de forma regular (utilizo 20 líneas) 
y conservadas en el mismo orden que los verbos en la cadena correspon- 
diente. En consecuencia, si decide que un verbo no ha de utilizarse después 
de todo o que ha de añadirse uno nuevo, puede ver, a simple vista, a 
dónde debe ir en la cadena de verbos y en el programa, sin tener que 
preocuparse por mantener el registro de cuántos hay o de qué VERBO 
debe establecerse (como es habitual, ha de ponerse los verbos más 
frecuentemente utilizados primero en la lista, al principio en las cadenas 
de verbos y al principio en el bloque del programa). 

Finalmente, existe la lista de los nombres. Esta es probablemente la 
lista más importante. Contiene los nombres de todos los objetos y las so- 
luciones de las que forman parte, asi como los números de línea de las 
rutinas de verbos que les utilizan. Los nombres están listados en el orden 
en que están contenidos en los arrays o() y 0S(), que corresponde 
aproximadamente al orden en que deben encontrarse los GETs y NEEDs 
en el programa para su resolución. Es importante disponer de una lista 
completa porque las rutinas de nombres, al ser los puntos finales de una 
serie de llamadas, en raras ocasiones pueden mantenerse en una forma 
muy lógica y, por consiguiente, serán difíciles de localizar durante la 
depuración del programa. Las sentencias REM ayudarían a resolver este 
problema, pero se necesitarían tantas que el tamaño de programas se 
podría hacer doble y habrían de suprimirse de la versión acabada. 


7.2 Conversación con los monstruos 


El hecho de matar a los monstruos y de robar todo lo que atesoran resulta 
muy atractivo, pero no todos los monstruos son hostiles y algunos pueden 
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ser demasiado poderosos para que les incite a luchar un aventurero 
molesto. En tales circunstancias, el aventurero astuto emplearía otras 
armas tales como el halago engañoso, la persuasión suave, juramentos 
sonoros, amenazas escalofriantes o cualquier otra forma de conversación 
que parezca ser probable que aparte al monstruo de su presa. Sin 
embargo, ello significa que el monstruo debe ser capaz de mantener una 
conversación y ello es algo difícil de simular. 

En una microcomputadora son posibles dos métodos. Podemos aspirar 
a una simulación lo más completa posible en la que se realicen muchas 
pruebas y transformaciones en el lenguaje, se hagan tentativas carentes de 
sentido y se utilice un vocabulario amplio y variado. O bien, podemos 
utilizar un par de trucos de prestidigitación, que hagan parecer que se 
permite la conversación pero que realmente se limiten a hacer cosas 
aleatorias con las palabras. 

El primer método es muy complejo y demasiado difícil para que nos 
podamos concentrar en su descripción completa, pero se pueden adaptar a 
las microcomputadoras algunas de sus rutinas de utilidad que podemos 
encontrar en muchos libros especializados en programas. Dichas rutinas 
están basadas en dos procedimientos: uno de ellos se relaciona con el 
hecho de que en el procesamiento de la entrada el programa comprueba 
las palabras clave comparando cada palabra de entrada con respecto a un 
diccionario de palabras que tiene reconocidas y, según la coincidencia que 
se encuentre, compilará una cadena de salida con un significado adecuado, 
y en el otro procedimiento se actúa sobre la base de que en el procesa- 
miento de esa salida se realizan algunos cambios en la estructura para 
que se adapte, desde el punto de vista gramatical, a la cadena de en- 
trada. 

Un ejemplo del primer procedimiento sería una prueba para una 
palabra tal como “lucha”. Si se encontrara esta palabra, el monstruo 
podría responder con “puesto que quieres luchar, hazlo” y el control 
podría conmutarse a la rutina de combate. Un ejemplo del segundo 
método sería la transformación de pronombres, en donde si la primera 
cadena es algo como “le daré mi espada”, entonces, la salida podría ser 
“de acuerdo, tomaré su espada”. 

Lo anterior exige un gran esfuerzo de concepción. Lo menos que se 
requiere de una rutina adecuada para que haga la tarea antes indicada es 
que debe tener un vocabulario amplio y apropiado, que debe proporcionar 
sentencias razonablemente gramaticales, que debe permitir la introduc- 
ción de cadenas más largas que de dos palabras y que la respuesta debe 
estar relacionada con la entrada. 

Ello significa que tendríamos que considerar a todas las palabras que 
sean probable que se produzcan y encontrar alguna respuesta adecuada 
para cada una de ellas, lo que podría exigir mucho más trabajo que lo que 
justifica el programa. Sin embargo, el diseño esencial es fácil de describir 
(Figura 7.1). 
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. ACEPTAR CADENA DE ENTRADA 

. SEPARAR LA CADENA EN LAS PALABRAS COMPONENTES 

. RETENER TODAS LAS PALABRAS EN LA MEMORIA 

. COMPARAR TODAS LAS PALABRAS DE ENTRADA CON RES- 

PECTO AL DICCIONARIO DE PALABRAS CLAVE 

5. SI SE ENCUENTRA UNA PALABRA CLAVE, ENTONCES EJE- 
CUTAR LA SUBRUTINA ADECUADA 

6. SILA SUBRUTINA UTILIZA LA CADENA ORIGINAL, ENTON- 
CES HACER LAS TRANSFORMACIONES NECESARIAS EN ESA 
CADENA 

7. SINO SE ENCUENTRA NINGUNA PALABRA CLAVE, ENTON- 
CES EJECUTAR UNA SALIDA POR DEFECTO 

8. SILA PALABRA CLAVE ENVÍA EL CONTROL A OTRA RUTI- 

NA, ENTONCES EJECUTAR ESA RUTINA; DE NO SER ASI, 

PASAR AL PRINCIPIO DEL BUCLE DE CONVERSACION 


Figura 7.1 


Hull — 


Las etapas 2 y 3 son simplemente expansiones de las rutinas que ya hemos 
utilizado para analizar las entradas de dos palabras; esto es, búsqueda de 
espacios y retención de todos los elementos de datos entre espacios como 
palabras separadas. La etapa 4 tomará cada palabra de forma sucesiva y 
cada palabra en el vocabulario de base de datos efectuará la comparación 
de cada dos de ellas. Ello podría ser un proceso muy largo, sobre todo si la 
cadena de entrada o el vocabulario es grande. Se puede acelerar algo el 
proceso utilizando un código de tres o de cuatro letas en lugar de la 
palabra completa para su coincidencia (pero ello podría dar lugar a 
coincidencias falsas), ignorando todas las palabras de menos de cuatro o 
de más de seis letras (porque estas palabras es probable que no sean 
habituales o que sirvan para fines gramaticales pero no para fines 
semánticos) y utilizando un sistema de indexación, basado en el alfabeto o 
en los códigos de los caracteres, de modo que la búsqueda pueda 
bifurcarse a través de la base de datos en lugar de ir examinando cada uno 
de los elementos de datos. 

Por ejemplo, supongamos que la cadena de entrada era “deme sus 
joyas o le corto la cabeza, hágalo inmediatamente”. Al consultar nuestro 
diccionario, el método más sencillo sería tomar una a una cada palabra y, 
utilizando bucles FOR... NEXT, comparar cada una de ellas con las 
existentes en el diccionario. Pero es improbable que cualquier respuesta 
interesante pueda introducirse en el programa para relacionarse con 
“sus”, “o”, “le”, “la” o “inmediatamente”, que es por lo que estas 
palabras están fuera de nuestro límite de longitud de las palabras. En caso 
de que se trabajara con un idioma en el que hubiese palabras con signos de 
puntuación internos, también se podrían suprimir. Ello significa, en este 
ejemplo, que una cadena de diez palabras se quedará reducida a cinco. 
Para cada una de estas cinco, el programa podría efectuar la comparación 
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palabra a palabra, pero si disponemos nuestro diccionario de tal manera 
que las palabras se puedan comparar de forma alfabética, tal como 
utilizando varios arrays de cadenas, se podrá reducir mucho el número de 
pruebas a realizar. Si suponemos que solamente “deme” está contenida en 
este diccionario y la comparación se hace de forma alfabética, solamente 
se tendrían que realizar dos pruebas para averiguar una coincidencia, 
puesto que el programa mira primero la palabra “corto” y luego “deme”. 

La etapa 5 es el núcleo fundamental del programa. Para cada palabra 
clave deben permitirse una o más salidas posibles. Estas últimas se 
podrían seleccionar de forma aleatoria una vez que se haya dirigido el 
control a ellas o bien, se podrían motivar de alguna otra forma, tal como 
se expone en el Capítulo 8. Para nuestra cadena de muestra, también se 
podría utilizar algunas transformaciones. Por ejemplo, la rutina de 
“deme” podría tomar todas las palabras comprendidas entre “deme” y el 
final de la cadena de entrada o una conjunción (en este caso “o””) e invertir 
cualquier pronombre encontrado en esa subcadena con el fin de conseguir 
“dele mis joyas”. Para esta operación, la rutina añade “si yo” y “qué me 
dará?”. Por consiguiente, la fórmula de salida es: 


“Si yo” + cadena de entrada transformada + “que me dará?” 


que proporciona la respuesta perfectamente significativa: “si le doy mis 
joyas, qué me dará?”. Obsérvese que para hacer lo anterior, el programa 
solamente necesita reconocer una sola palabra clave. No precisa saber 
cuáles son las joyas, ni a quién se hace referencia. 

La salida por defecto utilizada si no se encuentra en ninguna palabra 
clave, contendría varias opciones de comentarios evasivos, tales como 
“dígame algo más”, “ello es fácil de decir para usted”, “no comprendo”, 
etc. Incluso con un programa de procesamiento de cadenas de la primera 
clase, estos comentarios se utilizarán más que cualquier otro, por lo que se 
necesita una amplia gama para evitar demasiadas repeticiones. 

En principio, rutinas como las anteriores se podrían utilizar a través de 
las aventuras completas, y no solamente en comunicaciones con los 
monstruos. Sin embargo, en la práctica ello no se hace así, por los mismos 
motivos que muchos otros potenciales de aventuras no se pudieron 
realizar: Lleva demasiado tiempo la codificación, se utiliza demasiada 
memoria, hay muchos problemas que se plantean en el diseño de los 
algoritmos adecuados y la razón más poderosa, que nadie se lo ha 
planteado seriamente. 

La opción más fácil se ha utilizado con bastante éxito. Ello implica la 
utilización de más medios de subterfugio que la conversación real, aunque 
los principios sean bastante semejantes a los que se acaban de exponer. En 
este caso, no se ha hecho ningún intento de “comprender” la cadena de 
entrada, sino más bien que el monstruo haga una elección más o menos 
aleatoria entre un conjunto de respuestas que tengan sentido dentro del 
contexto. 
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Por ejemplo, al jugador se le puede dar una opción simple entre luchar 
y hablar con un monstruo. Puede elegir la última opción porque su 
fortaleza no es grande y puede decir: “tengo mucho afecto por los 
duendes”. Hay muchas respuestas posibles a dicho comentario: el 
monstruo podría pedir más información, podría mostrarse colérico, 
podría hacerse muy amigo, podría mostrarse precavido o podría adoptar 
una actitud falaz. Todas estas posibles actitudes se pueden expresar 
mediante frases que no tienen relación con la que se dijo con anterio- 
ridad: 


Digame algo más. 

¿Todo lo que puede decir es que tiene mucho cariño por los duendes? 
Estoy contento de que haya dicho eso. 

¿De verdad es eso lo que piensa? 

Tendrá que darme algún tiempo para pensar en una respuesta. 


Al estar desconectada con la cadena de entrada, estas últimas se 
pueden elegir de forma aleatoria, y, con tal de que sea razonablemente 
compatible, esta parecerá tener sentido y podría, a la larga, llevar al 
combate o a la entrega del tesoro o a que el monstruo se apodere del 
protagonista o a cualquier otra acción del monstruo que esté codificada en 
el programa. 

Una rutina de muestra para lo anterior, que se podría añadir al 
programa de las Minas de Merlín, se da a continuación: 


3800 LETR =0 

3805 PRINT “Que tiene que decir?” 

3810 LET R = FNR(B) + R 

3820 INPUT AS$ 

3822 IFR < 1 THEN GOTO 3950 

3825 GOTO 3830 + (Rx*5) 

3830 PRINT “Estoy harto de esto, me iré”: RETURN :REM VUEL- 
VE A LA RUTINA PRINCIPAL 

3835 PRINT “Es ello lo que realmente siente?”: LETR = R + 1: 
GOTO 3810 

3840 PRINT “Yo no le comprendo del todo”: LET R = R — 2: 
GOTO 3810 

3845 PRINT “No tiene nada mejor que decirme que eso?”: LET R = 
R + 1: GOTO 3810 

3850 PRINT “Por ello no me gustaría comerle?”: LET R = R — 3: 


GOTO 3810 

3855 PRINT “Desea entonces ser amigo?”: LET R = R — 5: GOTO 
3810 

3860 PRINT “Me estoy impacientando”: LET R = R + 3: GOTO 
3810 


3865 PRINT “Detesto a los aventureros como usted”: LET R=R +2 


3870 PRINT “Le podría dar una recompensa si se comportara 
amablemente”: LET R = R — 5: GOTO 3810 

3875 PRINT “Odio a las personas que dicen cosas como esa”: LET R 
= R + 3: GOTO 3810 

3880 PRINT “Haría mejor teniendo cuidado con mi cólera”: LET R 
= R — 1: GOTO 3810 

3885 PRINT “Tiene una posibilidad más de ser amable”: LET R = R 
— 2: GOTO 3810 

3890 PRINT “LE AVISE!!!*: GOSUB RUTINA DE COMBATE: 
RETURN 

3895 PRINT “Porque pienso que es tan rudo me apoderaré de su 
tesoro”: LET (variable del tesoro) = 0: RETURN 

3900 PRINT “Atiborrate como una diversión”: LET (variable del 
tesoro) = 0: GOSUB RUTINA DE COMBATE: RETURN 

3905 PRINT “El monstruo sufre un ataque de apoplejía y expira en el 
suelo”: LET (variable del tesoro) = (tesoro del monstruo): 
RETURN 

3950 PRINT “Pareces tan amigo que te voy a prestar todos mis 
ahorros ganados con mi esfuerzo”: LET (variable del tesoro) = 
(variables del tesoro) + (tesoro del monstruo): RETURN 


Lo anterior actúa de forma bastante sencilla aumentando y disminu- 
yendo R de acuerdo con un factor aleatorio y de acuerdo con la cadena de 
salida elegida. Cuando R disminuye, es más probable que el monstruo 
done su tesoro; cuando R aumente, es más probable que monte en cólera. 
Sin embargo, si se hace realmente iracundo, puede tener un ataque como 
resultado y si R llega a hacerse 1, el monstruo puede hartarse y alejarse. 
Las cadenas están algo confusas de modo que se tenga la seguridad de que 
R puede fluctuar, porque los monstruos son notoriamente temperamenta- 
les. Sin embargo, la variable aleatoria añadida cada vez siempre tenderá a 
empujarle, a enfurecerse, por lo que cuanto más larga sea la conversación 
mantenida por el protagonista, tanta mayor probabilidad habrá de que 
llegue a enojar al monstruo. 

La rutina se puede expandir, o contraer, fácilmente añadiendo y 
suprimiendo líneas y se pueden añadir otros resultados mediante el 
empleo de otros valores de R para dirigir el control a otras rutinas o bien, 
elaborando otras variables. Asimismo sería posible incorporar comproba- 
ciones simples de la entrada del jugador para afectar a estas variables. Por 
ejemplo, un diccionario de palabras groseras se podría utilizar como una 
base de datos para comprobar la entrada, en donde dos de dichas palabras 
harían enfurecerse al monstruo de forma inmediata. 
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“CHROME” 
$ (AMBIENTACION) 


8.1 La necesidad de la ambientación (“Chrome”) 


El término “Chrome” es una palabra utilizada por los diseñadores de 
juegos de tablero para referirse a la decoración y a los detalles adicionales 
que podría tener y que no afecta a la estructura del juego o de su 
ejecución, pero que, incluso así, puede ser esencial para el atractivo del 
propio juego. En un juego de tablero, este término incluiría las narracio- 
nes relativas al escenario, en carácter atractivo de los contadores, el diseño 
de la caja, la información de los antecedentes, las características de 
presentación especiales, variantes adicionales, etc. Su finalidad y efecto es 
muy similar al de una carrocería de un vehículo, en el sentido de que es 
muy atractiva, aumenta el precio, no añade nada positivo a la prestación 
del vehículo, pero que puede ser muy importante para hacer que el 
presunto comprador se decida a su adquisición. En nuestro caso, se trata 
de atraer a un jugador. Hace que el juego sea espectacular y único en su 
género, prescindiendo de cómo sea la ejecución real. Por consiguiente, 
aunque no sea estrictamente necesario, esta caracteristica puede ser 
esencial para la sensación producida por un juego y para su efecto total 
sobre los jugadores, aun cuando la forma y el diseño del juego propiamen- 
te dicho no sea destacable. 

El éxito de un microjuego tal como “Star Trek” (“emigración a través 
de las estrellas”) depende tanto de su apariencia y de su temática como de 
su posibilidad de ejecución y del diseño. El jugador puede desempeñar el 
papel del Capitán Krik y vigilar las visualizaciones en pantalla exactamen- 
te lo mismo que haría un capitán de una nave espacial real (cualquiera que 
ésta sea). 

Los juegos deficientemente concebidos prestan poca atención a la 
ambientación. En lo que respecta al diseñador lo más importante es la 
estructura del juego y no lo que dicha estructura ha de representar. Esta 
concepción ha llevado a diseñar unos juegos de acción rápida de carácter 
abstracto y de poca calidad para la microcomputadora que, aparte de su 
apariencia exterior, tiene poco que ofrecer en el sentido de estimular la 
inteligencia o la imaginación. Los programadores no son necesariamente 
las personas idóneas para la escritura de juegos. Muchos programas 
excelentes no son atractivos en su ejecución porque no hay nada original 
en su apariencia para atraer la atención del jugador. Por el contrario, hay 
algunos juegos con una escritura muy deficiente que, debido a su buena 
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presentación y a su atractiva envoltura, se vende mucho mejor que lo que 
merece su programación. 

El objetivo del buen diseñador es elegir una estructura de juego que no 
sólo sea interesante de ejecutar sino que también sea una representación 
fiel de una realidad. Utiliza detalles, efectos, gráficos, sonido, formato de 
visualización, lenguaje y documentación para crear una atmósfera dentro 
de la cual la estructura lógica del programa del juego sea una parte 
esencial y coherente. 

Por lo tanto, así cualquier cosa que realce la apariencia del juego y haga 
su lógica algo real y no abstracto (más como una simulación que como un 
juego abstracto; esta es la diferencia entre el juego del Monopoly y el juego 
de Damas) es probable que haga un juego mejor, sobre todo si añade 
variedad a dicho juego. No es nuestra intención sobrecargar el juego con 
detalles superficiales o elementos similares que nunca entrarán realmente 
los jugadores en la ejecución. Algunos juegos de tablero tienen el 
inconveniente de tener tantas reglas y contadores, tantos detalles de fondo, 
documentación y texto de soporte, que los jugadores nunca llegan a 
profundizar en estos detalles ni a comprender y sentir el atractivo de 
ejecutar el juego. Por consiguiente, en condiciones ideales, la lógica del 
juego debe representar a la lógica de la realidad, que se está “simulando” 
y la ambientación debe ser suficiente para poner en evidencia que la lógica 
del juego es también la lógica de un mundo particular. 

Por ejemplo, una forma de añadir interés y variedad a un juego de 
fantasía o de ciencia ficción, sea o no un microjuego, es generando nuevos 
nombres para las personas y los lugares en el juego. Ello podría realizarse, 
con bastante sencillez, eligiendo una secuencia aleatoria de letras a partir 
del alfabeto y enlazándolas para constituir una nueva palabra. Sin 
embargo, la palabra resultante podría ser algo como “ZXZQXL”, que no 
es muy similar a ninguna palabra real. En realidad, parece ser una serie 
aleatoria de letras. 

Si pretendemos hablar en inglés o en español, hay determinadas reglas 
acerca de las secuencias de letras que hay que respetar en esos idiomas, tal 
como el hecho de que una Q siempre va seguida por una U, o que una 
palabra siempre tiene, como minimo, una vocal. Verdaderamente hay 
muchas de dichas reglas y resultan posible escribir un programa que 
contenga palabras inglesas, o españolas, porque dicho programa puede 
aplicar todas esas reglas al encadenar letras. Sin embargo, no necesitamos 
llegar a tales longitudes para la creación de palabras que sean variadas, 
originales, fantásticas, pero sin dejar de ser suficientemente similares al 
idioma para que se consideren como palabras reales y, por consiguiente, 
una representación suficiente de la realidad con plena significación. Un 
programa que haga lo anterior podría realizarse con una capacidad de 2K 
para la mayor parte de las máquinas y es probable que se pudiera 
comprimir en una capacidad menor. Todo lo que se necesita hacer es tener 
en Cuenta las reglas siguientes: 
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. Las palabras están constituidas por sílabas (normalmente entre 1 y 4). 

2. Una sílaba es una secuencia de sonidos, que está constituida por un 
grupo de ninguna a tres consonantes seguido por un grupo de una o dos 
vocales y después, un grupo de ninguna a tres consonantes. 

3. Algunos grupos de sonidos o de letras se producen con más frecuencia 
en el idioma normal que otros. 

4. Algunas letras no pueden seguir a otras letras (por ejemplo, en inglés la 

F no va seguida por una N en la misma silaba, y en español, después de 

una N no puede ir una B). 


El programa debe elegir primero una vocal y luego, decidir cuántas 
consonantes precederán a la vocal y cuántas le seguirán. A continuación, 
ha de elegir una secuencia de consonantes, comprobando que pueden 
seguir unas a otras de forma admisible. Hecho lo anterior con los grupos 
de consonantes decidirá si habrá alguna sílaba más en la palabra. De esta 
forma se obtendrá una palabra similar a las idiomáticas. 

Las formas de variar el tipo del lenguaje implican esencialmente el 
cambio de una de las reglas 1 a 4 anteriores. Por ejemplo, podríamos 
permitir solamente palabras de más de dos sílabas, podríamos modificar 
la frecuencia relativa de las letras (en la Figura 8.1 se muestra la frecuencia 


Número relativo 
Letra de ocurrencias 


Z 1 
Xx 1 
J 1 
Q 1 
K 2 
v 3 
B + 
P 1 
G 4 
Y 5 
W 5 
E 6 
M 7 
$ 7 
L 10 
D 11 
R 15 
H 15 
S 20 
N 20 
T 22 


Figura 8.1. Frecuencia relativa de las consonantes en inglés 
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relativa de la ocurrencia en el idioma inglés, lo que se puede controlar 
utilizando sentencias DATA para contener estas letras y cambiando el 
número de veces que una letra particular está incluida en esta sentencia), 
podríamos cambiar el número de consonantes antes o después de las 
vocales y podríamos alterar las reglas que permiten las secuencias de 
letras. Este último cambio podría producir algunas palabras muy extrañas 
porque hay algunas secuencias de letras que son casi imposible de 
pronunciar sin que haya algún otro sonido entre ellas. 

El diagrama de flujo que se muestra en la Figura 8.2 presenta un 
programa generador de lenguaje detallado de acuerdo con lo que acaba- 
mos de describir. He utilizado variables con nombres largos para una 
mayor claridad, aunque tendrían que cambiarse para el Spectrum BASIC. 
Una versión del programa para el Spectrum está disponible en un casete 
aparte. *El punto principal es que para hacer que dicha idea merezca la 
pena ha de tenerse una semejanza con un mundo real, con la incorpora- 
ción de todas las reglas correspondientes. No habrá por qué molestarse en 
proporcionar esta clase de ambientación a no ser que se haga todo lo 
menor posible. 


8.2 Inteligencia en la aventura 


En este caso, el término “inteligencia” no significa la inteligencia del ju- 
gador, sino la inteligencia de la máquina. La generación de nombres para 
su utilización en un programa o juego no concebido para microcomputa- 
dora es de utilidad, pero solamente constituye un aspecto superficial de un 
juego. Puede consumir memoria que podría ser de más utilidad en la 
estructura de juego propiamente dicho. Sin embargo, si está escribiendo 
un programa con un grado de inteligencia incorporado, ha de proporcio- 
nar originalidad al nivel del juego estructural fundamental. Un programa 
que pueda, en cierto sentido, “pensar” proporcionará un grado de 
variedad que no es superficial sino fundamental para el juego, con lo que 
hará a cada juego diferente pero de una forma significativa. 

Dichos juegos están comenzando a aparecer para su aplicación en 
microcomputadoras. Un éxito notable para el Spectrum ha sido el juego 
del Hobbit, que es un juego de aventuras en el que los personajes 
responden a las acciones del jugador pero también tienen ““vida propia” 
(por ejemplo, el programa “comprende” el concepto de “amigo” y 
“enemigo”, por lo que los monstruos se comportarán de forma diferente 
según la manera en que se les trate por el protagonista del jugador). Otros 
programadores están trabajando actualmente en juegos bélicos en los que 
el jugador ha de combatir con la computadora. La computadora toma 


* El diagrama de flujo y la descripción de un programa generador de lenguaje, aparecieron 
en el número 10 de The War Machine, agosto 1982. 
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ESTABLECIMIENTO DEL ARRAY DE CONSONANTES CO$(X), ARRAY DE VOCALES VW5(Y) 


y 
MEMORIZACION DE CONSONANTES Y VOCALES 
y 
VS$=""": SL$=": GP5="" e«—— 
y 
SY = RAND(1-4) | 
y 
y 
ELEGIR VOCAL 


y 
NV = RAND(1-3) 
SI NV=1 ENTONCES ELEGIR VOCAL SUPLEMENTARIA 


CN = RAND(O-3) 


¿ES CN = 0? e ¿ES CL = 0? — 


y 
CO = RAND(1-X) 
y 
GP$=GPS$+CO$(CO) 


y 
PROBAR ORDEN DE LAS CONSONANTES 
(SI FUERA INACEPTABLE HACER FL = 1) 


¿ES FL = 1? 
N 


¿ESJ=0N0 —% ES CL=1? 


IN N le 


J=J+1 SL$ = SL$ + GP» 
y 
SL$ = GPS + SLS GPg="" — 
y y Ss 
EL =:1 ¿ES | = SY?  —“——>WD$=WDS$+SL$ 
y A y 
GPS="" PRINT WDS$ 
I=1+1 y 
PRINT * ” 


y 
WDS = WDS + SLS 


y 
SL$ = *" 


X = NUMERO DE CONSONANTES A ELEGIR 
- Y = NUMERO DE VOCALES A ELEGIR 


LAS VARIABLES EN EL DIAGRAMA DE FLUJO SON: 


COS (NUMERO DE CONSONANTES) =ARRAY DE CONSONANTES 
NWS$ (NUMERO DE VOCALES) =ARRAY DE VOCALES 
SY NUMERO DE SILABAS POR PALABRA 
V NUMERO DE VOCALES ELEGIDO EN EL ARRAY 
NV CONTROLA EL NUMERO DE VOCALES POR SILABA 
CN NUMERO DE CONSONANTES 
SL$ CADENA DE VOCALES 
GP$ CADENA DE CONSONANTES ACTUAL 
WD$ PALABRA ACTUAL 
ZZ5 CADENA DEL ORDEN DE LAS CONSONANTES ACTUAL 
FL INDICADOR PARA ORDEN DE CONSONANTES 
Figura 8.2 CL INDICADOR PARA PRIMER O ULTIMO GRUPO DE CONSONANTES 
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decisiones estratégicas y tácticas que depende de lo que el jugador esté 
haciendo. Dicho de otro modo, parece “comprender” lo que el jugador 
está haciendo y tiene una amplia gama de posibles respuestas que se eligen 
de acuerdo con su comprensión de la situación. Una forma más avanzada 
en este área son los programas para juegos abstractos, tales como Ajedrez 
y Otelo, en los que la computadora puede derrotar, con cierta facilidad, a 
jugadores bastante buenos porque tiene un mejor conocimiento de las 
posibilidades tácticas. 

Estas clases de juegos emplean técnicas utilizadas en el campo de la 
inteligencia artificial. La inteligencia artificial es realmente una rama del 
estudio de la inteligencia humana. Su finalidad es aprender más acerca de ' 
la mente humana descubriendo lo que necesitamos conocer para hacer que 
una máquina actúe de una forma que podríamos considerar como 
humana. Sin embargo, ha llegado a ser muy importante en otras diversas 
áreas, tales como la robótica, sistemas de guiado de misiles y diagnosis 
médica. Puesto que la inteligencia es lo que se somete a prueba primaria- 
mente en los juegos que no son de acción rápida y como un juego es un 
mundo aparte, los juegos proporcionan una forma adecuada de desarro- 
llar técnicas distintas de inteligencia artificial y estas técnicas pueden, de 
forma potencial, constituir una nueva generación de juegos que sean 
mucho más atractivos que la selección actualmente disponible. 

Lo anterior se debe a que la inteligencia programada en un juego nos 
permite superar (o, al menos, tratar de superar) los dos problemas 
principales que se nos han planteado hasta ahora en la programación de 
juegos de aventuras. Por una parte está el juego de enigmas. Se trata de 
una prueba real de la inteligencia del jugador y de su imaginación, pero 
tiene el importante defecto de tener una estructura y un contenido fijos, 
por lo que una vez que se haya resuelto ya no se volverá a ejecutar. Por 
otra parte está el juego de combate. En lugar de estar determinado 
previamente, se trata fundamentalmente de una serie de estructuras 
aleatorias. El jugador tiene relativamente poco que hacer en el desarrollo 
de una estrategia inteligente y coherente y hay pocas posibilidades de 
predecir la forma en que podrían encajarse las diferentes partes del juego 
de aventuras. Los monstruos y los tesoros están distribuidos de forma 
aleatoria y las alteraciones en las variables, capacidades y características 
del protagonista son más o menos accidentales (dependiendo de las 
posiciones a las que se vaya y del momento en que se haga). Por ello 
aunque cada encuentro pueda ser interesante, su naturaleza fundamental- 
mente aleatoria llevará, a la larga, al aburrimiento. 

Lo que se precisa es un juego que se estructure por sí mismo, de modo 
que sea diferente cada vez que se juegue. Sin embargo, debe tener una 
estructura lógica, de modo que se pueda someter a prueba la inteligencia 
del jugador y que se pueda desarrollar estrategias y al mismo tiempo, sus 
cambios durante la ejecución deben responder a las decisiones previas del 
jugador no de forma aleatoria, sino de forma inteligente. La inteligencia 
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6.—Williams 


artificial puede proporcionar ideas y técnicas sobre cómo conseguir lo 
anterior. Lamentablemente, sin embargo, la generación actual de micro- 
computadoras tiene memoria insuficiente para grandes componentes de 
inteligencia artificial, por lo que de momento, sólo podemos investigar las 
posibilidades y tratar de encontrar nuevas formas de desarrollo. 

La clave para hacer que un programa se comporte de forma inteligente 
es hacerle comprender. Ello significa que ha de conocer no solamente lo 
que el jugador acaba de hacer, sino también lo que ha estado haciendo 
hace algún tiempo y lo que significan estas acciones (esto es, lo que el 
jugador es probable que haga en el futuro). Los programas de juegos 
normales están constituidos por una serie de respuestas inmediatas, 
basadas en lo que el jugador acaba de realizar. En el juego de enigmas, el 
jugador introduce por el teclado una orden y el programa interpreta esa 
orden y luego la olvida y se mantiene a la espera de la orden siguiente. En 
el juego de combate, el programa calcula el efecto de cada lanzamiento, 
luego lo olvida y espera que se produzca el siguiente. De esta forma realiza 
el cálculo de cada combate. Cuando ha concluido lo olvida y se pone a la 
espera del siguiente. 


Por el contrario, un programa inteligente recuerda lo que se ha hecho 
con anterioridad, trata de interpretarlo (descubriendo una estrategia O 
significado subyacente) y trata de predecir lo que podría suceder a 
continuación. De acuerdo con esa predicción, elaborará una respuesta que 
no estará basada en las últimas acciones del jugador, sino en la tendencia 
total de sus acciones y que no sea puramente conforme y dependiente, sino 
independiente, dirigida por los “objetivos” del propio programa. 

Por ejemplo, examinemos el concepto de enemigo/amigo antes men- 
cionado. Un diagrama de flujo simple para la comprensión de este 
contexto, podría ser el que se da en la Figura 8.3. 


. EL JUGADOR ACTUA HACIA EL MONSTRUO 

2. SI LA ACCION ES HOSTIL; ENTONCES SE TENDRA (LET) 
ENEMIGO = ENEMIGO + 1 

3. SI LA ACCION NO ES HOSTIL ENTONCES SE TENDRA (LET) 
AMIGO = AMIGO + 1 

4. SI AMIGO < ENEMIGO ENTONCES LUCHA CON EL PROTA- 
GONISTA 

5. SI AMIGO >= ENEMIGO ENTONCES DA RECOMPENSA AL 

PROTAGONISTA 


Figura 8.3. El concepto de amigo/enemigo 


pi 


Dicho de otro modo, ello implica el establecimiento de una variable 
para cada uno de los dos conceptos, con la actualización de las dos 
variables cada vez que el jugador realice una acción y comparando las dos 
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variables cada vez que se necesite una respuesta. En consecuencia, se 
necesitan también dos tipos posibles de rutina, una amistosa y una hostil. 
Tal circunstancia podría significar que para cada monstruo en el juego se 
precisan dos variables y dos conjuntos de rutinas de respuesta. Es evidente 
que ello es probable que doble la cantidad de memoria que necesitaremos 
para un número determinado de encuentros, aunque hay formas de 
reducir dicho consumo. Por ejemplo la dicotomía enemigo/amigo se puede 
incluir en una sola variable, con la hostilidad restándose del valor de esa 
variable y con la amistad en forma de adición a la misma. Por consiguien- 
te, si el número es positivo, la relación será amistosa y si fuera negativo, 
dicha relación será hostil. Asimismo, las mismas rutinas de respuesta se 
pueden utilizar con diferentes variables para diferentes monstruos. Incluso 
de esta forma, se precisa de más memoria para las rutinas “inteligentes”. 

Por cada grado de inteligencia que queramos añadir, aumentará los 
costes en memoria y en codificación. Por ello si deseamos registrar la 
generosidad frente a la tacañería, o la prudencia frente a la temeridad, o la 
locuacidad frente a la timidez, o la estupidez frente a la inteligencia, 
necesitaremos añadir variables y rutinas para cada uno de estos antagonis- 
mos. Aunque dichas adiciones realzarán notablemente el juego, lo que 
estamos añadiendo realmente es potencial. En cualquier ejecución particu- 
lar del juego, munca se utilizará muchas de estas rutinas. Un jugador 
hostil, generoso, precavido, locuaz y estúpido solamente haría uso de la 
mitad del juego. Potencialmente el juego sería mucho más interactivo y 
emocionante, pero parte de dicho juego no se utilizará. 

Este es el problema que se plantea con dicha programación. La 
inteligencia implica ser capaz de responder a una amplia gama de 
situaciones, por lo que habrá de ser objeto de programación, pero si no se 
produce una situación particular, no se utilizará la parte correspondiente 
del programa. 

Lo mismo es cierto cuando se escribe un juego que tiene una escritura 
por sí mismo. Es bastante posible elaborar un juego que esté estructurado 
de forma lógica y que sea diferente en cada ejecución, aunque sería más 
complejo que cualquiera de los dos tipos de juego que hemos examinado 
hasta ahora. Por ejemplo, una versión del juego de enigmas de Camelot, 
podría elegir entre un conjunto de tipos de enigmas posibles cada vez que 
se ejecutare. Supongamos que tuviera la elección de anagrama, cifrado y 
problema de la raíz cuadrada. Elige “cifrado”. A continuación, utiliza la 
rutina del cifrado para obtener un cifrado real y lo retiene en memoria 
como el problema particular a resolver. Entonces, examina todas las 
posiciones vacías en el juego y toma una para la retención de dicho 
cifrado. A continuación, elige otra posición vacía y pone a 1 un indicador 
que señaliza: ““si no se han resuelto el cifrado, esta posición está 
bloqueada”. 

Entonces, selecciona entre varias descripciones posibles la descripción 
real utilizada “su camino está bloqueado por una puerta con una 


153 


cerradura de combinación”. Finalmente, comprueba que un recorrido es 
posible entre las dos posiciones. 

El proceso que se acaba de describir es muy similar a los procesos 
descritos anteriormente en este libro con más detalle, para guiarme a 
través de la tarea de escribir su propia aventura. Dicho de otro modo, 
dicho programa estaría haciendo lo que un programador podría hacer y 
realizándolo de forma inteligente. Sin embargo, implicaria como mínimo, 
ocho rutinas que no incorporamos en nuestro juego, junto con la memoria 
suplementaria y las variables para incluir las elecciones posibles, y ello 
solamente establecería un tipo de posición. Si se tratara de un enigma 
semántico, tal como el basado en un juego de palabras, se precisaria un 
conjunto diferente de rutinas. 

Por consiguiente, parece improbable que las microcomputadoras, tales 
como el Spectrum, puedan servir de soporte a tales juegos complicados. 
Sin embargo, será posible concebir una sucesión de programas que 
“escribieran” juntos dichos programas originales. Por ejemplo, todas las 
ocho rutinas anteriores se podrían mantener como programas separados, 
proporcionando cada uno de ellos datos que se grababan en casete o disco 
o unidad de disco y luego se utilizasen como los datos para el siguiente 
programa en la secuencia. Con la velocidad y capacidad de discos o de la 
unidad de disco del Spectrum (Microdrive) tal como una sucesión 
generadora de juegos podria merecer la pena su desarrollo porque dicha 
sucesión se podria ejecutar mediante una sola orden como si se tratara de 
un solo programa y el resultado sería un juego estructurado original, 
como si el juego se escribiera por sí mismo. 

De forma análoga, el problema de mantener varias rutinas potenciales 
que pudieren no utilizarse, haciendo que las respuestas de la computadora 
y los protagonistas sean más “inteligentes”, también se pueden reducir 
con el empleo de discos. Si las rutinas menos utilizadas se conservan en 
disco, o unidad de disco, no necesitan emplear ninguna capacidad de 
memoria RAM de la computadora, salvo cuando sean objeto de llamada y 
de carga. Por consiguiente, la misma memoria RAM se podría utilizar 
para diferentes rutinas en diferentes momentos del juego. Sin embargo, 
solamente las microcomputadoras de alto coste, tal como la computadora 
Apple, tienen actualmente dichos juegos de aventuras e incluso estas 
computadoras tienen un tiempo de respuesta notablemente más largo para 
un juego particular. 

Incluso de este modo, es posible mejorar notablemente los tipos 
existentes de juego, incluso dentro de los límites de la generación actual de 
microcomputadoras. Una forma de hacerlo es combinar los tipos de 
juegos de enigmas y de combate. Hay uno o dos juegos que lo han 
intentado, pero algunos programas que reivindican haber tenido éxito en 
este aspecto, son realmente varios juegos separados que se enmascaran 
como uno solo. 

Si ha comprendido los principios en los que se basan ambos tipos de 
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juego, debe encontrar fácil la mejora de dichos juegos y, en consecuencia, 
puede encontrar la forma de su integración. Por ejemplo, es una tarea 
relativamente fácil añadir posiciones de combate al juego de enigmas. Una 
posición particular se podría atravesar sin necesidad de resolver un 
problema sino simplemente luchando con un monstruo. Dicha lucha 
podría ser objeto de ayuda, o de obstaculización, por los objetos que el 
personaje del jugador lleva en ese momento. Una espada podría hacerle 
luchar mejor y una tabla podría serle molesta. Mediante un dispositivo tal 
como el anterior, se puede añadir una dimensión suplementaria al juego 
de enigma puesto que el jugador no puede tener la certeza de que un 
conjunto particular de objetos siempre le conducirá al éxito. 

De forma análoga, el juego de combate puede contener posiciones de 
enigmas. Supongamos que la recompensa por destruir una nave espacial 
enemiga es que nuestro protagonista consiga su cargamento. Este último 
podría ser combustible o municiones, en cuyo caso mejora simplemente 
las capacidades de lucha de la nave victoriosa. Sin embargo, también 
podría ser un objeto sin el cual la nave no podría ir a una posición 
particular, por ejemplo, podría ser un mapa de un nuevo sistema solar o 
una llave electrónica para una puerta espacial, o un sistema de guiado 
para su utilización en campos de asteroides. 

De esta forma, los enigmas, las estrategias de combate, e incluso las 
acciones rápidas en tiempo real se pueden combinar en un solo juego. La 
variedad no es solamente de estructura y contenido, sino también de 
ejecución. El jugador tendrá que tomar decisiones de diferentes clases y en 
diferentes combinaciones, que sirvan de prueba de la totalidad de sus 
capacidades y no solamente de un conjunto limitado de ellas. 

También es posible utilizar técnicas como las empleadas en inteligencia 
artificial para realizar un juego sin tratar de llegar a conseguir completa- 
mente que el programa supere cualquier eventualidad. Por ejemplo, en el 
juego de combate es una cuestión relativamente simple mantener un 
registro del número de victorias que el jugador ha conseguido sobre una 
clase particular de monstruo. Si este registro indica que el jugador tiende a 
derrotar a una clase de monstruo pero huye ante otra clase, el programa 
puede modificar el juego de modo que haya pocos de los monstruos 
“fáciles” y más de los “difíciles””. O bien puede mantener un conteo de los 
monstruos matados y utilizar este dato como una variable que determine 
la fortaleza del siguiente monstruo encontrado. 

La inteligencia se podría incorporar también en una rutina como la 
que se describe en la Sección 7.3 para la comunicación entre el monstruo y 
el protagonista. Por ejemplo, supongamos que su programa mantiene el 
registro del número de duendes que el jugador mata y del número que 
dicho jugador trata de sobornar o utilizar alguna otra táctica. Este dato se 
puede utilizar como un índice de “amistad/hostilidad para con los 
duendes”. Supongamos que el jugador se encuentra ante un duende muy 
poderoso y no quiere luchar con él. No dispone de ningún dinero, por lo 
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que no puede sobornarle y necesita el tesoro que custodia dicho duende. 
Su única opción es hablar. En la base de datos del programa habrá varias 
palabras clave a buscar en la rutina de conversación y cada una de ellas 
tendrá un cierto valor, tal como se indica a continuación: 


Palabra Valor 
perverso —-3 
agresivo —-2 
feo —1 
agradable +1 
inteligente +2 


La rutina de conversación, que ha detectado dicha palabra, añade su 
valor al índice de hostilidad y de amigabilidad. Si el índice se hace inferior 
a —9, el monstruo atacará. Si se hace superior a +9, el monstruo 
entregará el tesoro. De cualquier otro modo, siempre que el jugador no 
ataque, tratará de conversar, pero su respuesta dependerá del nivel actual 
del índice de hostilidad. 

Si el índice es —8, podría decir ““vete enano repugnante”, pero si es +8 
podría decir “estoy contento de que hayas llegado porque estuve buscando 
a alguien a quien dar mis diamantes”. No sería necesario tener una táctica 
conversacional diferente para cada valor de límite si no hubiera espacio 
para almacenar una gran cantidad de texto y la variedad en la salida se 
puede conseguir combinando frases. De nuevo, estas frases tendrian que 
valorarse en el margen del índice (—9 a +9), pero algunas frases podrían 
tener una amplia gama de valores, por ejemplo: 


Número Valor para la 

de hostilidad 

frase Frase de salida 
1 ESTOY CONTENTO DE QUE HAYAS 

LLEGADO +7a +9 

2 ODIO A LOS ENANOS —6a —9 

3 PORQUE -=9a +9 

4 VETE —5a-—9 

SH Y =9a +9 

6 PERO -9a +9 

7. ME GUSTAN LOS ENANOS +6a +9 

8 ERES UN ENANO REPUGNANTE —4a -—9 

9 DIME MAS COSAS =1a +7 

10 TE DESPELLEJARE VIVO -8a -—9 

11. TENGO ALGO PARA TI -3a4+4 

12 VOY A PERMITIRTE QUE LO TENGAS =Sa+3 


Las frases utilizadas en cualquier momento particular se elegirían de 
modo que se adaptaran sensiblemente y que todas fueran permitidas por 
el índice de hostilidad actual. Una variedad todavía mayor se puede incluir 
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en dicha salida añadiendo variables o palabras elegidas de forma aleatoria. 
Por ejemplo, la frase 8 se podría retener como “TU” + AS$(R) + NS, en 
donde A£$() es un array de adjetivos insultantes, R es un número aleatorio 
y NS incluye la clase de personaje que el jugador ha elegido (brujo, elfo, 
enano, etc.) Acumulando pequeños elementos de esta forma se puede 
incorporar una gran complejidad a un juego con el empleo de una 
cantidad relativamente pequeña de memoria y dicha complejidad tendrá 
plena significación y no será aleatoria. 

No ha de olvidarse que si ponemos una variable o un conjunto de 
datos en nuestro programa para una cierta finalidad, podemos utilizarle 
para muchos otros objetos. Por ejemplo, una rutina simple puede 
utilizarse para permitir a los monstruos proporcionar pistas para la 
localización del tesoro como la recompensa por la victoria, en lugar de 
entregar el tesoro propiamente dicho. Dicha rutina puede utilizar los datos 
ya existentes y proporcionarse como una verdad o una mentira. 

Por ejemplo, podríamos desear que la salida fuera “respeta mi vida y te 
diré en dónde está x”. El monstruo podría saber en dónde está x o podría 
no saberlo y como x sería una de las posiciones de los elementos del tesoro 
en algún lugar en el programa, no se precisaría ninguna variable nueva 
para decir la verdad. Sin embargo, si el monstruo ha de mentir, tendrá que 
elegir un tesoro de entre el conjunto de tesoros posibles y una licalización 
para el mismo. Dicha tarea se realizaría con la rutina siguiente: 


99 REM RUTINA PARA MONSTRUOS MENTIROSOS 

100 LET R = INT(RND+3) +1 

110 IFR = 1 THEN LET L = posición del tesoro: LET T$ = 
nombre del tesoro$: GOTO 140 

120 LET R = INT(RND+*4)+1: LET L = INT(RND=-20)+1 

130 FOR [I = 1 TO R: READ TS: NEXT I 

140 PRINT “Si respetas mi vida te diré en dónde*;T$” está" 

150 REM (el jugador respeta la vida del monstruo) 

160 PRINT “El “¿TS” está en”;L 

189 RETURN 

190 DATA corona de plata, collar de oro, rubi, esmeralda 


La línea 100 decide si se trata, o no, de una mentira. Hay una 
probabilidad de 1 entre 3 de que el monstruo diga la verdad (por supuesto, 
algunos monstruos podrían ser más veraces que otros, en cuyo caso 3 se 
sustituirá por la variable de veracidad). La línea 110 establece las variables 
TS y L para el nombre del tesoro y la localización verdadera respectiva- 
mente y luego envía el control a las líneas de salida. 

La línea 120 selecciona la mentira, eligiendo uno de cuatro tesoros y 
una de veinte posiciones. La línea 130 efectúa la lectura del nombre del 
tesoro en T$ utilizando la sentencia DATA en 180, que será la misma 
sentencia DATA utilizada para preparar originalmente el mapa. Las líneas 
140 a 170 dan salida a la información. En este caso, siete líneas del nuevo 
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programa añaden una nueva dimensión total al juego; podrían reducirse, 
por ejemplo, permitiendo el número aleatorio que determina si ha de 
decirse una mentira y también si ha de decirse la mentira real. 

Hay muchas formas de añadir nuevos aspectos a un juego básico 
utilizando la estructura existente. Los monstruos se pueden “disfrazar” 
como otros monstruos; los enigmas pueden utilizar datos ya definidos en 
el programa para otros fines; la subrutina utilizada para determinar el 
combate puede tener también diferentes parámetros o variables y utilizar- 
se para determinar si una puerta puede abrirse, si se hace saltar un cofre, si 
se despierta a un monstruo, etc.; un registro de generosidad se puede 
utilizar para determinar la magnitud de los sobornos necesarios (los 
monstruos piden más porque han oído que el jugador es generoso) el 
precio de los aditamentos, el carácter amistoso de las criaturas “buenas”, 
la posibilidad de que tenga éxito un soborno o la eficacia de la magia (los 
dioses recompensan a un jugador generoso); los insultos de entrada 
pueden ser “recordados” y utilizados más adelante acerca del jugador y 
los objetos que sean útiles en una situación pueden ser peligrosos en otra. 
¡Las posibilidades son ilimitadas! 


8.3 Sonido 


El sonido, como los gráficos, es una de las características que varía en 
gran medida de una máquina a otra. El Spectrum tiene realmente unos 
recursos de sonido bastante limitados. Aun siendo así, hay varias cosas 
que se pueden hacer con esta capacidad acústica para realzar un juego. 

La utilización más sencilla del sonido es como un reforzador o lo que 
es lo mismo, como una señal redundante, que comunica a un jugador lo 
que habría conocido ya a partir de alguna otra información a su 
disposición. Muchos juegos emiten un sonido (BEEP) en cada turno de 
juego para indicar al jugador que su turno ha concluido o emiten un 
sonido si el jugador se desplaza hacia una pared u otro obstáculo o para 
indicar que el juego ha terminado, etc. Muchos jugadores se irritan 
solamente por esta circunstancia, por lo que si elegimos elaborar dichas 
señales redundantes en nuestro juego resultará conveniente dar al jugador 
la opción de desconectar el sonido. 

Esto último se puede realizar con gran facilidad. Hay que incluir en la 
preparación del juego una interrogante sobre si se desea el sonido o no se 
desea y utilizar la respuesta para poner a 1 un indicador. En cada 
sentencia BEEP en el programa se incluye una prueba para comprobar si 
está puesto a 1 el indicador; si no fuera así, se realizará la función BEEP o 
se introducirá en la subrutina del sonido. La sentencia de prueba sería 
similar a la siguiente: 


IF INDIC = 0 THEN BEEP 0.1,20 


La otra utilización supérflua del sonido que puede ser irritante es el 
empleo decorativo. Algunas microcomputadoras tienen capacidades acús- 
ticas que, aunque posibiliten la emisión de tonadas, no son muy atractivas 
al oído. Por consiguiente, no es una buena idea utilizarlas para un efecto 
decorativo. Sin embargo, otras microcomputadoras tienen un sonido 
multicanal muy aceptable y se pueden transformar en sintetizadores 
admisibles. El Spectrum está más cerca de lo primero que de lo último, 
pero las tonadas que se pueden ejecutar en esta microcomputadora pueden 
ser bastante agradables. La irritación llega cuando dicha tonada se ejecuta 
por trescientaava vez. 

Las tonadas se pueden utilizar para introducir y finalizar los juegos. Al 
final, los juegos siempre se pueden interrumpir si el jugador la siente. Sin 
embargo, deben utilizarse dentro del juego con cuidado. Acaso dichas 
tonadas sean admisibles si se utilizan como fanfarrias de victoria O 
intermedios mientras el programa está preparando sus datos. Incluso.en 
este caso, si la tonada dura un tiempo largo, solamente se considerará por 
el jugador como un retraso innecesario. 

Si queremos música en nuestro juego tendremos que integrarla de una 
forma sensible. Una forma en los juegos de enigmas es hacer musical uno 
de los enigmas. Las tonadas se pueden utilizar como pistas, lo mismo que 
puedan hacerlo mensajes de otras clases. La pista podría estar en el título 
de la pieza (problema: ¿Cómo cruzaría el río? Pista: Melodía del submari- 
no amarillo), en la construcción de la música (problema: ¿Cómo atraería la 
atención del brujo? Pista: La Obertura de 1812, esto es, haciendo un ruido 
fuerte) o en la lírica de una canción, para la cual la microcomputadora da 
el tono (problema: ¿Por qué este valle sigue cambiando? Pista: El Sonido 
de la Música; esto es, “las colinas están vivas”). Si deseamos ser muy 
agresivos podríamos codificar un mensaje en notación musical, de modo 
que la “súplica” del mensaje se podría transmitir ejecutando las notas B, 
E y G (B=Si, E=Mi, G=Sol). 

En los juegos de combate, estas clases de utilización son rara vez 
importantes. Sin embargo, lo que sí es de utilidad es una señal que 
comunica a un jugador algo que no podría conocer de cualquier otro 
modo, tal como un aviso de que algo está a punto de suceder o está 
sucediendo. Por ello cuando un monstruo está en el siguiente recinto, o 
cuando los seres de otros mundos están simplemente a 50 parsecs 
(unidades astronómicas) de distancia o cuando el elemento vital del 
jugador se está desperdiciando poco a poco, un sonido bien temporizado 
será cualquier cosa menos irritante. Transporta exactamente la informa- 
ción necesaria en una forma reconocible. De hecho, la investigación ha 
puesto de manifiesto que los usuarios tienden a prestar más atención a los 
avisos audibles que a muchas otras clases de señales (una de las razones 
por las que los invaspres del espacio parecían tan apremiantes, fue el 
irresistible avivamiento de su ritmo). 

En el Spectrum, una de dichas utilizaciones es hacer sonar un tono de 
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corta duración (BEEP) siempre que se pulse una tecla, porque el teclado es 
tal que los jugadores pueden dudar si se ha registrado su pulsación, sobre 
todo si la entrada no se visualiza de forma inmediata en la pantalla. Ello 
puede realizarse mediante la orden POKE 23609,N, en donde N es la 
longitud del intervalo que queremos hacer sonar (BEEP). 

Si desea tener música en su programa, resulta tedioso seguir el teclado 
de BEEP junto con los valores correspondientes a cada nota, sobre todo si 
se repiten algunas notas o duraciones. Es preferible retener los parámetros 
para BEEP como datos en cualquiera de las formas que hemos examinado 
en capítulos anteriores (como variables simples, como arrays, como 
sentencias DATA o como cadenas). Recuerde, si utiliza una cadena, que el 
tiempo que dura el proceso de la cadena podría modificar la duración de 
las notas ejecutadas. Asimismo, téngase presente que BEEP interrumpe la 
temporización normal del Spectrum, que sostiene cualquier cosa más, por 
lo que si se produce en medio de una rutina en tiempo real debe dejarse 
espacio para la interrupción. Por supuesto, esta última característica 
puede utilizarse ventajosamente. Si queremos un retardo en nuestro 
programa siempre podemos utilizar PAUSE, pero si lo hacemos, nada 
más se hará al mismo tiempo. BEEP actúa de forma muy similar a 
PAUSE, con la salvedad de que no puede interrumpirse por el usuario 
pero hace algo más al mismo tiempo. Además de tocar una tonada o 
producir un efecto particular, la duración de la tonada proporciona 
también al jugador una idea de la cantidad de tiempo que ha transcurrido. 

Para generar efectos con el sonido del Spectrum necesitará experimen- 
tar y tomar notas de lo que hace y los resultados parecen producirse. Sin 
embargo, algunos efectos sencillos son fáciles de descubrir. Los cuatro 
más sencillos de programar son aumentar o disminuir el tono y aumentar 
o disminuir la duración. Un incremento en el tono con un decremento en 
la duración parece corresponder a una aceleración; una disminución en el 
tono con una disminución en la duración se asemeja a una deceleración; 
un tono que aumenta y disminuye regularmente suena como una sirena y 
un lento incremento en el tono seguido por una caída rápida asemeja a un 
objeto que trepa y luego cae, etc. 

Para poner de manifiesto algunos de estos efectos, el programa 
ilustrado en la Figura 8.4 permite que se cambien los valores del tono y la 
duración cuando el programa ejecuta y toca musicalmente el resultado. 


1 PRINT AT 1,01;" 1 PARA DISM 
INUIR TONO EN .1" 
2 PRINT " 2 PARA DISMINUIR TO 


NO EN 1" 

3 PRINT '" 9 PARA INCREMENTAR 
PASO EN 1" 

4 PRINT " O PARA INCREMENTAR 
PASO EN .1" 
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S PRINT AT 16,0;" a PARA DISM 
INUIR DURACION EN .01" 

6 PRINT AT 17,0; s PARA DISM 
INUIR DURACION EN .1" 

7 PRINT AT 18,0;" k PARA INCR 
EMENTAR DURACION EN .1" 

8 PRINT AT 19,0;" 1 PARA INCR 
EMENTAR DURACION EN .01" 

9 PRINT AT 0,10;"PULSE" 

10 LET p=0: LET d=.1 

SO IF INKEYS="1" THEN LET p=p 


51 IF INKEYS="2" THEN LET p=p 


55 IF p<-57 THEN LET p=-57 
60 IF INKEYS="0" THEN LET p=p 


61 IF INKEYS="9" THEN LET p=p 


65 IF p>69 THEN LET p=69 
70 IF INKEYS$="a' THEN LET d=d 


71 1F INKEYS="s" THEN LET d=d 

80 IF INKEYS="L" THEN LET d=d 

81 IF INKEYS="k" THEN LET d=d 

90 1F d<0.02 THEN LET d=0.02 

95 PRINT AT 10,10;" DURACION : 
">sSTRÍ$ (d)7" 

96 PRINT AT 12,10;" PASO:";STR 
$ (p;" "” 


100 BEEP d.p 
150 GO TO 50 


Figura 8.4 
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ENIGMAS, TRUCOS 
Y TRAMPAS 


Este capítulo está dedicado a proporcionar un conjunto de componentes 
elementales, enigmas y problemas que se pueden incorporar a un juego 
para aumentar su variedad y su interés. Comenzaremos examinando la 
orden favorita del protagonista de nuestros juegos, que no es otra que la 
orden HELP (AYUDA) y luego, estudiaremos parte de las cosas a las que 
podría aplicar dicha ayuda. 


9.1 La orden HELP (AYUDA) 


En cualquier etapa en un juego de aventuras, el jugador se puede 
encontrar en una situación en la que no sepa qué hacer a continuación 
(sobre todo, en un juego de enigmas, o en que haya olvidado algún 
elemento de información fundamental, tal como los sortilegios que se 
pueden utilizar en el juego de combate). La orden HELP puede servir para 
dos funciones: puede proporcionar al jugador unas pistas que le saque de 
su situación indecisa y también puede dar al jugador olvidadizo algunos 
elementos que le sirvan de recordatorio. Ambas funciones se pueden 
emplear en el mismo juego, pero se suelen disponer de una sola. Para 
utilizar mapas, probablemente sea preferible tener dos órdenes: HELP 
para las pistas y la orden INSTR(ucciones) para las instrucciones. Si está 
utilizando una entrada de palabras completas, la orden INSTR solamente 
necesitará efectuar la llamada de las mismas rutinas de instrucción que 
para la preparación inicial o un subconjunto de las mismas. Sería un 
despilfarro de capacidad el empleo de una rutina de instrucción diferente a 
no ser que se ponga de manifiesto que en las instrucciones permitidas son 
realmente parte del juego. 

Por ejemplo, en un juego del espacio, la nave espacial puede desplazar- 
se alrededor de artefactos agrupados procedentes de una civilización 
arcaica y cada artefacto podría permitir una acción diferente por parte de 
la nave (tal como un desplazamiento más rápido, una mejor detección, 
armas nuevas, etc.). Podríamos no desear que el jugador sepa de que 
dispone de dichas posibilidades hasta que se hubiere encontrado con el 
artefacto correspondiente. Una forma de hacerlo sería dar a cada artefacto 
un número de código y mantener un registro de todos los números en 
posesión de la nave/jugador (con el empleo de un método similar al de 
agrupamiento de objetos en Camelot). A continuación, cuando la orden 
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INSTR fuera objeto de entrada, se llamaría varias rutinas de instrucción 
independientes, una para cada artefacto. 

La orden HELP puede ser más complicada. La clase de pistas ofrecidas 
puede depender de la posición actual, de las capacidades y de las 
posesiones del protagonista. Su forma más simple se suele encontrar en el 
juego de enigma, en donde una sola pista está disponible en cada posición, 
no cambiándose dichas pistas en absoluto. Por consiguiente, si el jugador 
encuentra una puerta atascada, al teclear HELP puede obtener la respues- 
ta: “las bisagras están oxidadas”. Ello debiera ser una pista suficiente para 
sugerir la necesidad de un engrase de las bisagras. En algunos casos, no se 
podría disponer de ninguna pista, por lo que se precisa una respuesta 
evasiva como la respuesta por omisión, tal como: “parece ser que lo está 
haciendo bien” o “no considero que usted merezca ninguna ayuda”. 

Ello significa que ha de mantenerse una serie de cadenas, una para 
posición que necesite una pista y una cadena por defecto para todas las 
demás posiciones. Al teclear HELP se enviaría el control a una rutina que 
imprimirá la cadena que sea adecuada para la posición correspondiente. 
La forma más fácil para conseguir dicho ascceso condicional a las cadenas 
es utilizando un array que contenga todas las cadenas, en donde el 
subíndice del array es el número de la posición actual. El inconveniente de 
este procedimiento es que las posiciones sin pistas seguirán disponiendo de 
un espacio reservado en el array, lo que constituye un desperdicio de 
memoria. Por consiguiente, nos encontramos ante un caso en el que se 
precisaría una sentencia GOTO condicional (de la que no dispone el 
Spectrum). La sentencia correspondiente en Microsoft o BBC BASIC sería 
(si hubiera cinco posiciones posibles): 


EN POSICION GOTO 5005, 5030, 5015, 5030, 5025 


en donde 5030 se utiliza dos veces porque es la respuesta evasiva. Cada 
una de las sentencias 5000 a 5030 imprimiría la pista correspondiente. 

En el Spectrum BASIC tenemos que ser más astutos. Utilizamos una 
sentencia GOTO con una variable obtenida a partir del número de 
posición. Si no se dispone de una pista, ha de pasar a través de dos 
sentencias GOTO, del modo siguiente: 


800 GOSUB 5000 
4999 REM RUTINAS PROPORCIONADORAS DE PISTAS 
5000 GOTO 5000 + (POSICION +x10) 
5010 PRINT “Las bisagras están oxidadas”: RETURN 
5020 GOTO 5060 
5030 PRINT “Las cerraduras necesitan llaves”: RETURN 
5040 GOTO 5060 
5050 PRINT “Qué clase de hierba necesita esperar?”: RETURN 
5060 PRINT “Lo está haciendo estupendamente”: RETURN 
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Las clases de pistas dadas no deben hacer la solución demasiado fácil 
ni hacer que el enigma se pueda resolver sin mucho esfuerzo. Su objetivo 
es colocar al jugador en la situación correcta sin dar explícitamente la 
solución. Un ejemplo sería la línea 5050 anterior: “¿Qué clase de hierba 
necesita esperar?”. La respuesta es “tomillo”, pero la pista no dice al 
jugador que sea dicha hierba. Simplemente, le hace pensar, aunque no 
tanto como si no dispusiera de dicha ayuda. 

Hemos de tener presente, cuando se escriba las órdenes HELP, que 
conjuntos de condiciones diferentes pudieran ser ciertas en una posición en 
tiempos diferentes. Por ejemplo, en una cárcel el jugador puede tener que 
pasar a través de las etapas siguientes para poder escapar: 


. Obtener una comida. 

. Encontrar la lima oculta en la comida. 

. Limar sus esposas. 

. Romper una pata de la cama. 

. Utilizar la pata de la cama para alabear los barrotes de la ventana. 


QU 4 uy non — 


Ello es probable que se señalizara mediante un indicador que se 
incrementaría desde O a 5; cuando alcanzara el valor 5, el jugador podría 
escapar. Por lo tanto, si se tecleó la orden HELP, mientras el jugador 
se encontraba en dicha posición, podrían ser necesarias cinco ayudas 
posibles. Estas ayudas tendrían que conseguirse mediante una combina- 
ción de dos pruebas: una que envíe el control a la rutina de posición y la 
otra, dentro de esa rutina de posición, para elegir la pista correcta de entre 
las cinco disponibles. Por consiguiente, se tendría: 


5000 GOTO 5000 + (POSICION +10) 

5010 REM CARCEL 

5011 GOTO 5011 + INDICADOR 

5012 PRINT “Tengo hambre”: RETURN 

5013 PRINT “No me gusta el pastel apelmazado”: RETURN 

5014 PRINT “Una lima es un objeto fácil de manejar”: RETURN 

5015 PRINT “Ahora hay que deshacer la cama”: RETURN 

5016 PRINT “Simplemente una pata a través de la ventana y 
estaremos libres”: RETURN 


También podríamos desear hacer las órdenes HELP más específicas, de 
modo que se hagan pruebas para ver si el jugador tiene los objetos 
necesarios para las acciones correspondientes; de no ser así, hay que 
recordarle ese hecho. Por ejemplo, podríamos comprobar que Cad tenía 
todos los objetos necesarios para pasar a la siguiente etapa de la aventura 
antes de entrar en dicha etapa y la orden HELP podría indicar lo que 
pudiera haberse omitido. 
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9.2 Un enigma de anagrama 


Una rutina de enigma simple que no ocupa demasiado espacio y que, no 
obstante, se puede utilizar una y otra vez en un juego es el enigma de 
anagrama. La rutina indicada en la Figura 9.1 utiliza palabras extraídas de 
las sentencias DATA y sería posible emplear sentencias ya existentes en el 
programa para alguna otra finalidad a incluir en esta rutina, con tal de 
que fueran cadenas y que estuvieran organizadas en la forma correcta. Si 
se dispone de memoria de repuesto, se puede añadir un vocabulario 
especialmente complejo, pero no es necesario. 

Para utilizar las sentencias DATA existentes ha de procederse en la 
forma que se indica a continuación. En primer lugar, hay que cerciorarse 
de que dichas sentencias se han leido de forma adecuada para su finalidad 
primaria (v.g., si han de ser objeto de lectura en arrays de cadenas). A 
continuación, hay que restaurar (RESTORE) el puntero de datos (DATA) 
al principio de la cadena de DATA que se utilizará por la rutina de 
anagrama. Si se trata de las primeras sentencias DATA en su programa, 
sólo necesita restaurar al principio de la rutina del anagrama; si las 
sentencias correspondientes no son las primeras, hay que poner RESTO- 
RE n, en donde n es el número de línea de la primera sentencia DATA 
pertinente. Sin embargo, si utiliza sentencias DATA en cualquier otro 
lugar en el programa, tendrá que cerciorarse de que restaura (RESTORE) 
el puntero de datos al principio del conjunto de datos que precisa. 

La rutina del anagrama actúa de la forma siguiente. En primer lugar, 
se selecciona una palabra a partir de los datos. Esta palabra elegida se 
retiene en W$ y en V$. A continuación, la línea 20 genera un número 
entero aleatorio, R, que está en el margen de 1 a la longitud de la palabra 
elegida. La linea 30 añade a la cadena Y$ (que es inicialmente una cadena 
vacia) el R-ésimo carácter de la palabra de entrada, V$. La línea 40 
suprime la R-ésima letra de V$. La linea 45 comprueba si hay caracteres a 
la izquierda en V$ y si fuera así, repite el proceso de elección de carácter 
aleatorio. Las líneas 50 a 90 piden una respuesta y continúa con su 
interrogante hasta que se encuentre la respuesta correcta. Ello tendría que 
cambiarse en un juego completo. 

Lo anterior es solamente una rutina ilustrativa y se debe modificar 
para cualquier modificación práctica. Al jugador se le debe permitir 
solamente un número limitado de conjeturas y alguna opción para 
finalizar la rutina. Tal como están los números y los signos de puntuación 
se tratarán todos ellos como si fueran palabras o partes de palabras. Ello 
podría ser de utilidad (por ejemplo, podríamos necesitar que la computa- 
dora generara un código de cuatro dígitos como la combinación para una 
utilización segura y luego, aplicarles la rutina de anagrama para dar una 
pista parcial al jugador), pero, por lo general, los anagramas son 
solamente palabras y por ello tendríamos que comprobar que todos los 
caracteres seleccionados eran códigos comprendidos entre 65 y 90 o entre 
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97 y 122 (letras mayúsculas y minúsculas, respectivamente). Ello sería 
todavía más importante si el juego dependiera de la introducción del 
teclado correspondiente a su palabra elegida. Sin embargo, todo ello son 
simples adaptaciones. Los problemas que se pueden crear a un jugador 
con el empleo de dicha rutina están en correspondencia con la tarea que la 
rutina podría necesitar. 

Hay muchos enigmas de tipos similares que se pueden incorporar 
como elementos de juegos de aventuras grandes. En cierto sentido, todas 
las aventuras son realmente una serie de pequeños juegos enlazados 
(varios enigmas y/o pruebas de estrategia y reacción que están relaciona- 
dos en su totalidad). Camelot incorpora pruebas de lógica, pruebas de 
imaginación (o, para hacerlo más claro, juegos de palabras) y pruebas de 
aptitud verbal. Otros pequeños juegos que se pueden incluir implican 
enigmas matemáticos, pruebas de conocimientos generales, pruebas de 
cifrado (como el juego de Mastermind), o pruebas del lenguaje (tales como 
sinónimos, acrónimos o abreviaturas). 


5 LET V$="”: LET Y$ =**” 

10 LET R = (RND « 10)+1 

15 FOR I = 1 TO R: READ V$: NEXT I 

20 LET WS$ = VS 

25 LET R = INT (RND + (LEN(VS)) + 1 

30 LET Y$ = Y$ + VS(R) 

40 LET V$ = VS(1 TO R—1) + VS(R + 1 TO LEN (V$)) 

45 IF V$ <> *“” THEN GOTO 20 

50 PRINT Y$; “ es un anagrama de qué palabra?” 

60 PRINT “Sírvase teclear su respuesta” 

70 INPUT AS 

80 IF AS = W$ THEN PRINT “Correcto”: GOTO 100 

90 PRINT “Errónea. Pruebe de nuevo”: GOTO 50 

100 STOP 

110 DATA “bumerang”, “guión”, “catástrofe”, “elefante”, “casca- 
da”, “cormorán”, “computadora”, “aventura”, “programador”, 
“análogo” 


Figura 9.1. Rutina de anagrama 


9.3 Una rutina de cifrado 


En otro lugar examinamos la posibilidad de utilizar una rutina que 
pudiera generar nuevos cifrados para cada juego. El programa que se 
incluye en la Figura 9.2 es una rutina muy sencilla que selecciona, de 
forma aleatoria, una de cinco formas para obtener una cadena para dicho 
código. 
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1 
2 
3 
5 
8 
10 
15 
16 
20 


REM RUTINA DE CIFRADO 

REM z$5=respuesta correcta 
REM x$=cadena visualizada 
DEF FN R(x)=INT (RNDx*x) +1 
RANDOMIZE 

LET r=FN RC(2) 

LET ZE" 

LET x$=""" 

LET c=FN r(3)x2 

IF c=6 THEN GO SUB 200: GO 


TO 35 


30 
35 
RINT 
36 


GO SUB 100+((c+r)x*10) 
PRINT "CADENA CLAVE ";z$: P 
"CADENA CODIFICADA ";x$: 
PRINT : PRINT "PULSE 'A' P 


ARA OTRA CADENA"' 


37 


IF INKEYS<>"A' AND INKEYS<> 


"a" THEN GO TO 37 
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PRINT 

GO TO 10 

sToOP 

REM cuatro enteros aleatori 


FOR 1=1 TO 4 

LET r=FN r(9) 

LET z$=z$+STR$ (Cr) 

NEXT 1 

LET x$=z$ 

RETURN 

REM Cuatro letras aleatoria 


FOR 1=1 TO 4 

LET r=FN r(26) 

LET z$=z$+CHR$ (64+r) 
NEXT 1 

LET x$=z$ 

RETURN 

REM cuatro enteros aleatori 


LET r=FN r(8)+1 

GO SUB 130 

LET x$="" 

FOR i=1 TO LEN (z$) 

LET x=VAL (2$(1))+r 

IF x>9 THEN LET x=x-9 

LET x$=x$+STRS$ (x) 

NEXT 1 

RETURN 

REM cuatro letras aleatoria 


s codificadas 


161 
162 


GO SUB 140 
LET r=FN r(26) 


167 


163 LET x$="" 

164 FOR 1=1 TO LEN (25) 

165 LET x=CODE (z$(G1))+r 

166 IF x>90 THEN LET x=x-26 

167 LET x$=x$+CHR$ (x) 

168 NEXT 1 

169 RETURN 

200 REM codificar una palabra r 
eal 

201 LET r=FN r(20) 

202 REM el numero entre parente 
sis = tl total de palabras posib 
Les 

205 RESTORE 260 

210 FOR i=1 TO r 

220 READ z$ 

230 NEXT 1 

240 GO SUB 162 

250 RETURN 

260 DATA "PUERTA",''GAREA"',""TIRO 
" "RELLENO",'""CARRO" 

265 DATA ''MANO”,''CABEZA",''BOFET 
ADA”,'"'BRAVATA"',''LEON"" 

270 DATA ''CABRA'"',''VIAJE"','""SALTO 
"" "SALUD", '"'DESPEÑADERO" 

275 DATA ''AYUDA"',''LUNA",'"DOMINI 
0", '"'VIRUTA",''PLOMO"' 


Figura 9.2 


Proporciona dos cadenas, X$ y Z$, impresas en la línea 35. Cada vez 
que se ejecute (RUN) el programa, a Z$ se le asignará una cadena elegida 
y X$ retendrá una versión de Z$, que se visualizará en algún punto en el 
resto del juego. En dos de las cinco elecciones, X$ y Z$ serán coincidentes. 
Por consiguiente, podrían utilizarse como “llave” y “cerradura”. Un 
cuadrado NEED contiene Z$ y el cuadrado GET equivalente, que 
proporciona la información necesaria para pasar el cuadrado NEED, 
tendrá X$. Estos son códigos muy simples. Siendo cada uno de ellos una 
cadena de cuatro letras o de cuatro números. 

En otros dos casos, una cadena aleatoria se elige para llenar Z$ y 
luego, la cadena se manipula antes de que se retenga en X$. En el caso de 
los números, cada digito tiene un valor añadido (el mismo valor para cada 
uno de los cuatro) por lo que el jugador, al descubrir X$, debe descubrir 
también el valor que se ha restado de cada dígito para obtener la respuesta 
correcta. Una línea clave, en este caso, es la línea 156 que efectúa una 
prueba para ver si la adición del número elegido y el valor es mayor que 9; 
si lo fuera, divide por 10 y suprime la parte decimal del número. Ello hace 
más intrincada la elaboración de conjeturas. Por consiguiente, al jugador 
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se le debe exigir un “pago” por cada conjetura en el valor requerido, acaso 
con una reducción en inteligencia cada vez que cometa un fallo. 

La cadena de caracteres objeto de manipulación se transforma de una 
forma semejante. Cada letra en la cadena elegida se sustituye por otra 
letra situada en el alfabeto un número determinado de letras más allá. Si 
las letras llegan a sobrepasar a la Z, comenzarán de nuevo en A, de modo 
que, por ejemplo, X+4 corresponde a B. De este modo, el jugador tiene 
una tarea más dificil que con los dígitos puesto que hay 26 respuestas 
posibles al valor elegido así como un mayor número de combinaciones 
posibles de caracteres en la cadena original. 

La quinta elección toma una palabra real a partir de una de las 
sentencias DATA y la manipula en la misma forma que la cadena de 
caracteres aleatoriamente elegida. Ahora, el jugador tiene una mejor 
posibilidad porque puede utilizar dos elementos de información: todas las 
letras están codificadas por otras letras situadas a una distancia fija y la 
cadena completa tiene sentido. Si se añaden otras sentencias DATA, 
entonces, el margen del número aleatorio en la línea 201 habrá de 
cambiarse al número total de palabras posibles. 

Como es habitual con el empleo de las sentencias DATA, podría 
utilizarse cualquier sentencia DATA en el programa. Una posibilidad es 
incluir alguna forma de pista en la sentencia DATA, tal como los datos 
sobre las ubicaciones de un tesoro, con un desglosamiento de las palabras 
componentes. A continuación, el jugador puede descubrir la pista en la 
forma de una palabra cada vez, hasta que tenga un conocimiento 
suficiente para que sea capaz de averiguar la totalidad. Dicha utilización 
de este enigma, tendría, pues, cuatro etapas: hallazgo de las cadenas 
codificadas originales, determinación del “dinero” necesario para el pago 
exigido por las conjeturas, elaboración de la conjetura correcta y reunión 
de todas las palabras para constituir una pista coherente. Entonces, por 
supuesto, la propia pista podría ser secreta... 

Con el empleo del mismo tipo de diseño sería posible concebir 
alfabetos místicos (simbólicos) completos que los jugadores hayan de 
descifrar durante el juego (por ejemplo, en un juego como el de los 
Egipcios descrito en el Capítulo 2). En lugar de utilizar el alfabeto 
tradicional como la cadena de codificación, se puede emplear una cadena 
de gráficos definidos por el usuario, de modo que el jugador no tenga 
inicialmente ninguna idea sobre lo que representa ni de cómo encajan con 
el lenguaje normal. 

También es posible elaborar funciones de cadenas para actuar como 
simples dispositivos de codificación que se puedan aplicar en cualquier 
punto en el juego. Supongamos que tenemos una rutina que permite a 
Sages dar pistas relativas a las ubicaciones de artefactos valiosos. Una 
función tal como la que se indica a continuación podría aplicarse cada vez 
que dicha pista se proporcionara, de modo que se le de al jugador su 
información, con tal de que pueda decodificarla: 
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DEF FN AS(B5) = BS((LEN(BS)— 3) TO LEN (BS)) + BS(1 TO 4) + 
BS(5 TO (LEN (BS5)— 3)) 


en donde B$ es la cadena de la pista y debe tener más de ocho caracteres 
de longitud. Esta función simplemente efectúa una división en tres partes 
desiguales y realiza la recombinación, de modo que a la cadena real se le 
de una versión falseada del original. 


9.4 Teletransporte 


Una trampa ordinaria en muchas aventuras es el elemento de trama o 
(teleporter) que transporta al protagonista a algún destino desconocido en 
el ámbito del juego. En muchos juegos de enigmas, ello no se puede 
utilizar a menudo, porque el jugador ha de pasar a través de todas las 
posiciones en un orden más o menos determinado, pero en algunos casos, 
puede constituir una forma de enviar al jugador a la siguiente fase del 
juego (de modo que parezca que se ha perdido porque el entorno no le es 
familiar, pero que, en realidad, esté en el camino correcto a través de la 
estructura lógica del juego) o bien, una trampa limitada que haga retornar 
al jugador a una etapa anterior. Acaso ello pueda plantear un problema 
dependiendo de los objetos que lleve consigo el protagonista cuando se 
produzca dicho transporte. 

Sin embargo, el “transportador” aleatorio sólo se suele utilizar en 
juegos de combates en los que está implicado un laberinto de alguna clase. 
La rutina de dicho transporte calcula una posición aleatoria en el laberinto 
y luego, coloca al protagonista en dicha posición. Por consiguiente, sería 
posible que una rutina de esta naturaleza en el juego de Merlín localizara 
al jugador en una sección de las cavernas que no tenga ninguna salida a la 
superficie (aunque la fórmula utilizada lo hiciera improbable). Debemos 
utilizar este dispositivo solamente en recintos en donde podamos tener 
certeza de que hay una salida posible, tal como en el caso de los juegos de 
combates de mapa fijo, o tendremos que efectuar pruebas para cerciorar- 
nos de que existe una salida desde la posición que elabora la rutina. Esta 
última elección puede ser difícil. La más sencilla solución de compromiso 
es incorporar la insuficiencia como una parte bien patente del diseño 
imprimiendo un comentario que deplore la pérdida del jugador. 

Si deseáramos incorporar dicha rutina al programa de Las Minas de 
Merlín, tendríamos que hacerlo que se produjera en raras ocasiones (de 
modo que el jugador no resultara atrapado de forma arbitraria con 
excesiva frecuencia) y trataríamos de hacer máxima la posibilidad de una 
salida como se hace en la rutina siguiente: 


6500 REM TRANSPORTADOR 
6510 LET N = 100: GOSUB 2800 
6520 IFQ <> 1 THEN RETURN 


170 


6530 LET Z = FNR(3) + 1 

6540 LET X = FNRQ0) 

6550 LET Y = FNRQ0) 

6560 GOSUB 1000 

6570 IF MOV = 0 OR MOV = 2 THEN GOTO 6530 
6580 PRINT “Aaaaaaaaaaah!! Ha caído en un teleporter” 
6590 PRINT “Nunca podrá salir de aquí ahora” 

6599 RETURN 


Obsérvese la utilización de FNR(x) en esta rutina. Esta es la misma 
función que la que se definió en las Minas de Merlín en la línea 8020, 
tratándose de una función singular que se puede utilizar para generar 
cualquier número aleatorio en cualquier margen dentro de un programa. 
El número entre paréntesis en la llamada de la función define el margen de 
los números potenciales. 

Las líneas 6510 a 6520 deciden si existe un transportador (““teleporter”) 
en esa posición, utilizando el número aleatorio incorporado. La rutina 
supone que se ha llamado por otra rutina, probablemente la rutina de 
“riesgo” y simplemente vuelve allí si Q es cualquier valor que no sea 1l. 
Las líneas 6530 a 6550 establecen el nuevo valor para la posición, estando 
los valores de X y de Y dentro de un amplio margen pero Z estará 
limitada a los niveles segundo a cuarto solamente, por lo que el jugador 
no se enviará a un nivel demasiado profundo en el que no se tenga 
ninguna esperanza de volver a descubrir la superficie. La subrutina 1000 
calcula el nuevo movimiento y, si dicho movimiento no fuera posible, 
tratará de hacer todo de nuevo. Las líneas finales imprimen (PRINT) un 
mensaje adecuado y devuelven el control a la rutina que efectúa la 
llamada. 

Una trampa similar puede crear un laberinto patente sin la necesidad 
de un programa completo de elaboración de laberinto. Ello se puede 
utilizar mejor en el juego de enigmas pero se podría incorporar a un juego 
de combate con una pequeña modificación. La intención es dar la ilusión 
de un laberinto sin que se elabore realmente ninguno. Elaboramos un 
bucle sin fin que acepta todas las órdenes de movimiento pero que 
imprime, de forma continuada, un mensaje tal como “está perdido en los 
pasillos sin fin del laberinto”. Es evidente que ello no tendría mucho 
sentido en sí mismo, por lo que habria que establecer alguna forma de 
salir del laberinto (con el empleo del objeto correcto en la manera correcta 
o tecleando una orden adecuadamente inteligente) o establecer alguna 
clase de limite (tal como el empleo de un bucle muy largo que no obstante, 
tenga un final o permitiendo siempre la existencia de una dirección que 
conduzca al principio). En condiciones normales, los jugadores que 
penetren en este tipo de laberintos insistirán en realizar diez o veinte 
movimientos, hasta que consideren que no pueden hacer ninguno más con 
posibilidad de éxito, por lo que si establecemos un contador en el bucle de 
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modo que después de veinticinco movimientos se encuentre un objeto 
recompensaremos la perseverancia y haremos que el laberinto sea más 
atractivo. Si el protagonista Cad encuentra el objeto, es posible que 
considere que el laberinto existe realmente y que lo que ha de hacer es 
desplazarse alrededor del mismo en la forma habitual. Una versión 
sencilla de lo anterior es la siguiente: 


6600 REM UN PSEUDO-LABERINTO 

6610 PRINT “Está perdido en los pasillos de un laberinto sin fin” 

6620 GOSUB (rutina de órdenes) 

6630 IF (la orden es “No estoy asombrado”) THEN PRINT “Ha 
encontrado la salida” 

6640 IF (el desplazamiento es hacia el oeste) THEN LET CONTOES- 
TE = CONTOESTE + 1 

6650 LET CONTADOR = CONTADOR + 1 

6660 IF CONTADOR > 25 THEN PRINT “Ve una estatua de 
esmeralda”: GOSUB (rutina de objetos): LET CONTADOR = 0 

6670 IF CONTOESTE > 10 THEN PRINT “Hay un pequeño 
anciano en el pasillo”: GOSUB (pequeño anciano): LET CON- 
TOESTE = 0 

6680 GOTO 6610 

6690 RETURN 


Una vez más, esta rutina debe ser objeto de llamada por otra. Se trata 
de un bucle sin fin que contiene tres pruebas. La prueba 1, en la linea 6630, 
abandona el bucle si el jugador ha encontrado la frase secreta correcta. La 
prueba 2, en la línea 6660, descubre un objeto si el jugador ha llegado 
suficientemente lejos en el laberinto. La prueba 3 descubre un personaje si 
el jugador ha ido suficientemente lejos hacia el oeste. Obsérvese que los 
dos contadores se ponen a cero por medio de estas líneas, por lo que el 
jugador encontrará la estatua cada 25 vueltas. En consecuencia, una 
prueba adicional ha de incorporarse para ver si la estatua sigue allí, por lo 
que la rutina del “objeto” tendrá que poner a 1 un indicador adecuado si 
se ha tomado o destruido y la línea 6660 debe asegurar también que este 
indicador no está puesto a 1. Una estructura de prueba similar sería 
necesaria para el pequeño anciano. 


9.5 Soborno y apuestas 


En las Minas de Merlín solamente permitimos una respuesta simple a los 
monstruos: el protagonista podía huir o luchar contra ellos. Puesto que los 
encuentros con los monstruos constituyen los sucesos principales en dicho 
juego, vale la pena considerar algunas adiciones que pueda hacerle más 
interesante. Dos de dichas adiciones son el soborno y las apuestas. Ambas 
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adiciones traen consigo la misma clase de intercambio con probablemente 
el mismo resultado: el jugador pierde dinero y por ello es menos probable 
que sea capaz de comprar lo que necesita en otras posiciones. El soborno 
consiste en la petición por parte del monstruo de dinero o de algún otro 
obsequio con cuya condición el jugador podrá seguir su camino sin daño 
alguno, si el monstruo consigue lo que pide. Esta función se puede 
incorporar en una de dos formas: una de ellas consiste en que el jugador 
tenga una libre opción de la misma como una de sus estrategias y otra es 
que antes de que pueda realizar su elección, el monstruo le exigirá un 
tributo a manera de soborno. En la Figura 9.3 se muestra una forma de 
elaborar la rutina para adaptarse a nuestro juego. 


110 PRINT “Quieres:” 
120 PRINT “(L) Lucha” 
130 PRINT “(R) Retirada” 
140 PRINT “(S) Soborno” 
150 INPUT A$: REM PUEDE UTILIZAR INKEYS$ Y LA RUTI- 
NA DE COMPROBACION DE VALIDEZ EN LAS MINAS 
DE MERLIN 
160 LETG =0 
170 IF AS = “S” THEN GOSUB 3500: IF G = 1 THEN RETURN 
180 IF G = 2 THEN GOSUB (rutina de lucha) 
190 CLS: GOTO 110 
3500 REM SOBORNOS 
3510 LET R = FN R(dinero) 
3520 PRINT “Dice que aceptará”; R “piezas de plata” 
3530 PRINT “Pagarás?” 
3540 INPUT AS 
3550 IF A$(1) = “N” THEN RETURN 
3560 IF dinero < R THEN PRINT “Tratas de engañarme?”: LET 
G=2: RETURN 
3570 LET DINERO = DINERO—R 
3580 LETG = 1 
3590 RETURN 


Figura 9.3 


La variable “dinero” representa el total de piezas de plata que tiene el 
protagonista. En las Minas de Merlín es C(7). La rutina se puede mejorar 
haciendo que el monstruo pida armas u otros elementos que lleve el 
protagonista. Ello podría constituir la petición de retroceso si el protago- 
nista no tiene suficiente dinero o podría ser aleatoriamente determinada 
antes de que se ejecute la rutina. De forma alternativa, el monstruo podría 
robar todo el dinero que tiene el jugador si decidiera no efectuar el 
soborno. 
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La realización de apuestas es algo diferente puesto que existe la 
posibilidad de que el jugador aumente su dinero. Por supuesto, las 
apuestas se podrían efectuar con algo diferente al dinero, tal como 
elementos de protección o incluso la vida del protagonista, pero, en todos 
los casos, debe existir la posibilidad de que el protagonista gane algo de 
este encuentro. Puesto que las apuestas tienen su propio riesgo, no hay 
necesidad de combinarlas con cualquier otro tipo de rutina, por lo que 
podría ser una clase de encuentro completamente aparte. 

El elemento fundamental para una rutina de apuesta es la curva de 
probabilidad utilizada. La más sencilla sería una gráfica en línea recta, de 
modo que la posibilidad de ganar siga siendo la misma a través de todo el 
juego, prescindiendo de los resultados de apuestas anteriores o de la 
cantidad de dinero que se haya apostado. Ello se representaría por una 
fofmula como: R = INT(RNC+*3): IFR = 1 THEN PRINT “Tú ganas”. 
En este caso, el jugador tiene una posibilidad entre tres de ganar cada vez 
que haga una apuesta. 

La posibilidad de realizar apuestas resulta más interesante si hay una 
correlación entre la cantidad de la recompensa posible y el grado de 
riesgo. Podríamos establecer una tabla de ventajas, o de probabilidades, 
en la que cuanto más pequeña sea la posibilidad de ganar tanto mayor 
será la recompensa posible. De este modo, al apostar en una proporción 
de tres a uno proporciona a cada una posibilidad de ganar de uno entre 
tres, pero triplicaría su dinero si consiguiera vencer; el apostar en una 
proporción de doce a uno solamente da una posibilidad de victoria de uno 
entre doce pero si tiene éxito obtendrá doce veces la recompensa. Una 
forma sencilla de incorporar lo anterior en una rutina es pedir al jugador 
que establezca las ventajas que requiere y utilizar este dato en la sentencia 
aleatoria: 


100 PRINT “Cuánto te gustaría apostar?” 

110 INPUT A 

115 IF A > dinero THEN PRINT “Me temo que tu calculadora 
necesita unas pilas nuevas”: CLS: GOTO 100 

120 LET dinero = dinero— A 

125 PRINT “Por qué factor le gustaría multiplicar su “¿A;” piezas de 
plata?” 

130 PRINT “Sírvase teclear un número entre 2 y 20” 

140 INPUT B: IF B<2 OR B>20 THEN PRINT “Quizá tengas que 
aprender algo de matemáticas antes de jugar con las personas 
mayores?”: CLS: GOTO 120 

150 PRINT “Esto es magnífico”;¡A*B; “podrías ganar” 

160 LET R = INT(RND xB) + 1 

170 IFR = 1 THEN PRINT “Y ganastes!!!”; LET dinero = dinero 
+ R: RETURN 
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180 PRINT “Oh que vergúenza. Perdistes. No te preocupes sólo es 
cuestión de dinero” 

190 IF dinero > 0 THEN PRINT “Va otra apuesta?” 

200 INPUT AS 

210 IF AS(1) = “Y” THEN GOTO 100 


Cualquiera de los juegos de apuestas con microcomputadoras, tales 
como los de máquinas de frutas o de ruleta o de dados, se pueden adaptar 
para incorporarse como una subrutina en un juego más grande, teniendo 
las ventajas de unas posibilidades más complejas y variadas y unos 
gráficos que suelen ser interesantes. Una forma sencilla de probar el 
conocimiento de probabilidades del jugador es pedirle que haga una 
apuesta sobre el total de los puntos obtenidos con dos dados de seis caras, 
bien sea dándole la oportunidad de doblar la apuesta si gana (en cuyo caso 
le convendrá apostar por “siete” cada vez que juegue), bien sea relacio- 
nando las ganancias con las posibilidades. Por ejemplo, la tirada de dos 
dados dará una media de un 12 por cada 36 tiradas, por lo que podemos 
ofrecer con seguridad unas apuestas de 30 a 1 para un 12 y estar seguros de 
que el jugador perderá a largo plazo. 

Para hacer las cosas algo más dificiles para el jugador, podríamos 
facilitar la ganancia por apuestas en las primeras fases del juego, cuando el 
jugador puede necesitar toda la ayuda que pueda conseguir, pero ir 
aumentando la dificultad a medida que se avanza en el juego. El contador 
de tiempo podría ser un contador de tiempo real, un contador del número 
de movimientos que ha realizado el jugador o también, podría ser alguna 
medida del éxito actual del jugador, tal como su puntuación total o bien 
un contador que registre el número de veces que ha realizado apuestas 
satisfactorias con anterioridad. 

Otra opción a utilizar en los encuentros de monstruos es la rutina de 
conversación tratada en el Capítulo 7. Esta rutina también se puede 
relacionar con el soborno y las apuestas, de modo que si se encuentran 
palabras clave en estas circunstancias, el programa se conmuta al 
programa en la rutina correspondiente. 


10 GRAFICOS 


No hay ningún motivo por el que los gráficos deban utilizarse en un juego 
de aventuras, sobre todo en aquellos juegos tales como los juegos de 
enigmas en donde la mayor parte de la información, ha de ser de tipo 
textual. El empleo de gráficos en dichos juegos puede traer consigo un 
consumo de memoria que se podría utilizar más ventajosamente para 
mapas o datos, pero si hay una cierta cantidad de memoria que se ha 
quedado sin utilizar después de que se haya escrito los elementos 
fundamentales de un programa principal, se pueden mejorar, en gran 
medida, el atractivo del juego mediante la adición de los gráficos. Sin 
embargo, si se pretende utilizar alguna forma de gráfico en el juego, ha de 
tratarse de tomar la decisión correspondiente lo antes posible en el diseño. 
Ello asegura que sus gráficos son una parte funcional integrante del juego 
y no algo que se ha añadido y que no aporta nada fundamental al mismo 
y también es preciso cerciorarse de que se mantiene un control continuado 
del consumo de memoria a través de todo el proceso de diseño. 


10.1 Los gráficos y el Spectrum 


Existen tantos sistemas de gráficos de microcomputadoras populares que 
resulta imposible considerar muchos de sus aspectos en este libro. Si desea 
tener gráficos detallados y complejos en sus juegos, deben acudir a un 
libro especializado en la aplicación de gráficos al sistema particular que 
utilice. No obstante, algunos aspectos son bastante comunes y el Spectrum 
contiene varias funciones de gráficos que son semejantes a las existentes en 
otras máquinas. Las funciones gráficas fundamentales de las que se 
dispone en el Spectrum son: 


1. Gráficos de bloques (con el empleo de PRINT) 

2. Gráficos definidos por el usuario (con el empleo de PRINT) 

3. Gráficos de pixels de alta resolución (con el empleo de PLOT, DRAW y 
órdenes afines) 


Alguna forma de gráficos de bloques están disponibles en la mayor parte 
de las computadoras. Si imaginamos a la pantalla de la VDU (unidad de 
presentación visual) dividida en cuadrados, o posiciones de caracteres, 
cada bloque ocupará una de dichas posiciones. En el Spectrum, la pantalla 
de caracteres es de 22 líneas por 32 columnas, lo que da un total de 704 
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cuadrados. Cada uno de estos cuadrados es un array de 8x8 puntos y 
cada gráfico de bloques (incluyendo el alfabeto, los números y los signos 
numéricos) es una combinación particular de algunos de dichos 64 puntos. 
Si no comprende lo anterior, debe volverse a leer los Capítulo 15, 16 y 17 
del Manual del Spectrum. 

La forma más fácil de comprenderlo es considerar a cada bloque 
elemental de 8x 8 puntos como una página en blanco. En esta página se 
tiene varios puntos y si se une cualquier combinación de dichos puntos se 
obtendrá lo que se denomina una configuración o modelo. La única 
diferencia es que, en lugar de unir los puntos, la microcomputadora 
proporciona configuraciones mediante la activación y desactivación de los 
puntos. Los puntos que se activan, o se encienden, dan la configuración 
correspondiente (el color INK de los gráficos del Spectrum) y los que se 
desactivan, o apagan, dan el fondo (el color PAPER del Spectrum). 

La sentencia BIN del Spectrum nos permite controlar la totalidad de 
los puntos en un cuadro particular, por lo que podemos unir nuestros 
propios puntos o lo que es lo mismo, definir una nueva configuración y un 
nuevo carácter. Si, por ejemplo, deseamos tener un pequeño triángulo, 
podríamos trazarlo en una configuración reticular de 8 x 8 pixels, tal como 
se indica en la Figura 10.1. Este dibujo se puede representar como la serie 
de sentencias BIN que se indica en esa figura. Observará que hay una 
correspondencia directa entre la configuración de pixels que se utiliza y la 
configuración de “unos” en la sentencia BIN. Ello se debe a que cada fila 
en el bloque de caracteres se mantiene en memoria como un octeto (esto 
es, 8 bits de información binaria). La sentencia BIN nos permite direccio- 
nar cada bit en cada uno de estos octetos, indicando si están activados o 
desactivados (““uno” o “cero”). Ocho de dichos octetos constituyen un 
solo carácter. 


BIN 00000001 
BIN 00000011 
BIN 00000111 
BIN 00001111 
BIN 00011111 
BIN 00111111 
BIN 01111111 
BIN 11111111 


Figura 10.1 


Otras máquinas utilizan sistemas diferentes para hacer lo mismo. Por 
ejemplo, los gráficos definidos por el usuario en la computadora BBC 
utilizan un número comprendido entre 0 y 255 para representar a cada 
fila. Recordará que éste es el margen de números que se pueden tener 
mediante un solo octeto (u ocho bits), por lo que se puede deducir que 
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cada uno de los números 0 a 255 significará una combinación diferente de 
desactivaciones y activaciones de la fila correspondiente. Ocho de dichos 
números forman un carácter. 

En el Spectrum, podemos tener hasta 21 gráficos definidos por el 
usuario almacenados en las direcciones USR “A” a USR “U”: Dichos 
gráficos se pueden imprimir de la misma forma que las letras normales A 
a U, con el empleo del modo de gráficos del Spectrum (el modo de 
gráficos se obtiene pulsando las teclas Caps Shift y 9). Veintiún gráficos 
pueden parecer una cantidad importante, pero se pueden utilizar con 
bastante rapidez en una aventura con gráficos. Ello es así porque para 
crear gráficos nuevos e interesantes no suele ser suficiente un cuadrado 
definido por el usuario. Aunque un solo cuadrado pueda proporcionar 
formas simples, caras, naves espaciales, vehículos, camiones, etc., no 
puede dar suficiente detalle para dibujar objetos tales como ogros o 
dragones o edeicios complicados y artefactos. 

Para resolver este problema, tenemos que dibujar nuestro diseño no en 
un solo retículo de 8x8 sino en varios retículos adyacentes. Si nuestro 
objeto ha de tener un eje vertical largo, ha de ponerse dos retículos uno 
encima de otro. Si ha de tener un eje horizontal largo, habrá que poner los 
retículos adosados. Dibujemos un cíclope y un dragón. El cíclope será alto 
por lo que alinearemos los retículos como se indica en la Figura 10.2. 


BIN 00011000 
BIN 00111100 
BIN 01100110 
BIN 01111110 
BIN 00111101 
BIN 00011001 
BIN 00111101 
BIN 01011011 
BIN 01011001 
BIN 11011000 
BIN 00111100 
BIN 00100100 
BIN 00100100 
BIN 01100110 
BIN 00000000 
BIN 00000000 


Figura 10.2. Un cíclope 


Puede observar que para el cíclope tenemos 16 sentencias BIN en dos 
conjuntos de ocho. El primer conjunto es la cabeza y los hombros del 
monstruo y el segundo conjunto corresponde a su torso y piernas. Con el 
fin de poner estos dos caracteres juntos para constituir un monstruo, 
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hemos de tener presente que letras se almacena en cada parte. Haremos la 
parte superior “A” y la parte inferior “B”. 

Podemos controlar la impresión del monstruo con el empleo de la 
sentencia PRINT AT. Si imprimimos gráficos A en 10,10, entonces 
tendremos que imprimir (PRINT) gráficos B en 11,10. Ello significa que 
ha de realizarse un diseño de programa esmerado cuando se utilicen 
dichos gráficos. la mejor forma es utilizar una rutina corta para imprimir 
cada monstruo, aun cuando la rutina sea solamente una línea. Los 
parámetros de PRINT AT en la rutina tendrían que ser variables pasadas 
a la subrutina por medio del programa principal. De este modo, la rutina 
para imprimir un ciclope podría ser como la que se indica a continuación: 


8999 REM CICLOPE 

9000 PRINT AT Y,X; “(gráficos A)”: PRINT AT Y+1,X; “(gráficos 
B)” 

9010 RETURN 


Para dibujar el dragón, utilizamos tres bloques de ocho y los imprimi- 
mos en la misma línea, una después de otra, con lo que se tendrá: PRINT 
AT YX; “(gráficos C)”; PRINT AT Y,X+1; “(gráficos D)”; PRINT AT 
Y, X+2; “(gráficos E)”. La misma instrucción se puede escribir como 
PRINT AT Y,Z; “(gráficos C) (gráficos D) (gráficos E)”, por lo que 
resulta más fácil hacer una impresión de diseños horizontales que de 
diseños verticales. El dragón se muestra en la Figura 10.3. 


BIN 00011111 
BIN 00000011 
BIN 01000000 
BIN 11100000 
BIN 01000000 
BIN 01100001 
BIN 00110011 
BIN 00011111 


BIN 11000000 
BIN 11111000 
BIN 11111100 
BIN 00111110 
BIN 11111111 
BIN 11000100 
BIN 11000100 
BIN 00001111 


BIN 00000000 
BIN 00000000 
BIN 00100000 
BIN 00110010 
BIN 11111111 
BIN 10011100 
BIN 00000000 
BIN 00000000 


Figura 10.3 


El inconveniente de estos gráficos debe sernos obvio. Para conseguir 
una figura que parezca viva, debe utilizarse 2, 3 o incluso más bloques y 
con ello se reduce rápidamente los gráficos disponibles. Hemos utilizado 
una Cuarta parte de los bloques disponibles para crear dos monstruos, por 
lo que es de suponer que el juego de magnitud media sólo podría 
conseguir ocho o nueve elementos gráficos dignos de consideración. 

Hay una forma de subsanar lo anterior. Podemos redefinir nuestros 
gráficos de acuerdo con su finalidad actual. Supongamos que hemos 
utilizado todas las ranuras definidas por el usuario y que ahora deseamos 
utilizar el dragón en el programa. Siempre que no deseemos que todos los 
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demás gráficos y el dragón estén visualizados al mismo tiempo, podemos 
seleccionar tres de los gráficos definidos por el usuario que no se estén 
utilizando cuando se quiera el dragón y efectuar la lectura de los datos del 
dragón en dichas ranuras. Entonces, cuando ya no se necesite el dragón, 
podremos volver a efectuar la lectura de los datos originales. 

Para hacer lo anterior necesitaremos una rutina general para la lectura 
de las sentencias BIN, que reasigne también la letra que se está utilizando, 
todas las sentencias BIN separadas y una planificación cuidadosa. Si no 
planificamos bien todos los gráficos se harán confusos y las visualizaciones 
finalizarán con una superposición de ciclope, dragón y ogro. Por consi- 
guiente, resulta conveniente incluir antes de cada conjunto de sentencias 
BIN una línea REM que nos recuerde lo que representan las siguientes 
ocho líneas BIN y qué letra (dirección USR) incluyen. El primer bloque 
del cíclope podría almacenarse, pues, en un programa como el siguiente: 


6499 REM CABEZA DEL CICLOPE 
9500 DATA “a” 

9510 DATA BIN 00011000 

9520 DATA BIN 00111100 

9530 DATA BIN 01100110 

etc. 


Para efectuar la lectura de esta configuración en un bloque de gráficos 
existente, tendremos que realizar primero la restauración (RESTORE) del 
puntero de datos a la línea correspondiente. Para facilitar esta operación 
podemos apuntar a la línea REM, puesto que la sentencia RESTORE hace 
que se efectúe la lectura de los datos a partir de la siguiente línea después 
del puntero que tiene los datos correspondientes. De esta forma, encontra- 
remos mucho más fácil recordar lo que significa cada número incluido en 
la sentencia RESTORE. Por consiguiente, la rutina de lectura sería: 


999 REM PARA LA LECTURA DE GRAFICOS DIFERENTES 
1000 RESTORE 9499 

1010 READ M$: REM LETRA DIRECCIONADA USR 

1020 FOR 1 = 0 TO 7 

1030 READ N 

1040 POKE USR M$+ IN 

1050 NEXT I 

1060 RETURN 


Sin embargo, puesto que deseamos que el puntero de RESTORE sea 
también una variable, suele ser preferible tener una variable previamente 
declarada que utilizará RESTORE. Si cambiamos la línea 1000 a: 


1000 RESTORE monstruo 


la variable “monstruo” se habría establecido por el programa principal 
que transmite el control a esta rutina de lectura. Por ejemplo, supongamos 
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que el monstruo que se utilizó dependía de la fortaleza actual del 
protagonista del jugador. Entonces, la rutina que erectúa la llamada 
podría ser: 


500 LET Monstruo = 9000 + (FORTALEZA +*100) 
510 GOSUB 1000 


Recuérdese que las sentencias BIN del monstruo pueden ser variables 
en sí mismas y que podemos utilizar cero en lugar de BIN 00000000. 
Podríamos desear utilizar variables en estas sentencias DATA si un grupo 
de gráficos tuviera el mismo diseño básico. Por ejemplo, podríamos 
utilizar gráficos para indicar lo que el jugador lleva o transporta en un 
momento determinado, en lugar de visualizar un inventario. En tal caso, 
podríamos utilizar una disposición con cinco bloques de gráficos, tal como 
se ilustra en la Figura 10.4. 


BRAZO 
DERECHO 


BRAZO 


di IZQUIERDO 


PIERNA 
DERECHA 


PIERNA 
IZQUIERDA 


Figura 10.4 


Cada uno de estos cinco bloques podría modificarse de acuerdo con el 
estado actual del protagonista del juego. Este último podría llevar coraza 
de pierna, manoplas, un peto, botas o ninguno de estos elementos de 
protección; asimismo, podría llevar un escudo, cualquier número de 
armas, una antorcha, un saco o cualquiera de una multitud de objetos. 
Supongamos que deseamos mostrar que la antorcha fue encendida y que 
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está actualmente sujeta en la mano izquierda. El bloque de gráficos y, por 
lo tanto, las sentencias BIN, serían exactamente coincidentes para las 
antorchas encendidas y no encendidas, con la salvedad de que se añadiría 
una llama. Utilizando un conjunto de variables para el “brazo izquierdo” 
y otro conjunto para “antorcha” y un tercero para “llama”, podíamos 
conseguir los bloques de gráficos requeridos con la simple combinación de 
los conjuntos de variables correspondientes. 

Podemos utilizar los gráficos que hemos definido en exactamente la 
misma forma que los caracteres ordinarios o los gráficos de bloques. De 
este modo, se pueden imprimir, de forma repetida para conseguir 
configuraciones completas; se pueden dotar de animación o de movimien- 
to alrededor de la pantalla, tal como se verá en el juego de la Busca del 
Tesoro que se indicará a continuación; se pueden combinar con el 
conjunto de caracteres normalizados para conseguir efectos complejos; se 
pueden añadir a diseños de gráficos de bloques y finalmente, se pueden 
combinar en la misma posición de PRINT con el empleo de OVER. Ello 
significa que dos (o más) gráficos definidos por el usuario se pueden 
sobreimprimir en la misma posición de carácter de modo que, por 
ejemplo, una figura se puede mostrar como atravesando un portal 
imprimiendo primero el portal, luego imprimiendo la figura superpuesta y 
finalmente, imprimiendo de nuevo el portal. 

Asimismo, podemos utilizar un protagonista de gráficos singular en 
diferentes formas proporcionándole atributos diferentes. Esta es una 
forma económica de crear personajes “diferentes”. Por ejemplo, si 
definimos un hombre de gráficos simple con el empleo de BIN, luego 
podemos hacerle un duende imprimiéndole en azul o con un esqueleto en 
blanco, un mago utilizando BRIGHT, un fantasma atravesando paredes 
utilizando OVER, una criatura mágica con el empleo de FLASH, etc. De 
forma análoga, si vamos a diseñar una aventura gráfica con un mapa 
impreso, el mismo signo en el mapa puede significar cosas diferentes 
utilizando colores distintos. Una serie de triángulos irregulares pueden ser 
colinas, montañas, pirámides o mar; la vegetación podría ser un pantano, 
un bosque, un matorral, etc., con el simple cambio del color del signo. 

Se plantea un problema con los gráficos del Spectrum, incluyendo los 
gráficos definidos por el usuario. La función SCREENS(x,y) normalmente 
proporcionará el carácter encontrado en la posición x,y en la pantalla. Sin 
embargo, no reconocerá caracteres con códigos inferiores a 32 o superiores 
a 127. En consecuencia, no podemos utilizar SCREENS para comprobar 
si la pantalla está llena de gráficos definidos por el usuario o incluso por 
gráficos de bloques. De este modo, un juego que desplace a un “aventure- 
ro” gráfico a través de la pantalla en la búsqueda de monstruos y de 
tesoros no actuará si el programa está concebido para depender de los 
símbolos visualizados para estos elementos. 

Hay tres formas simples de resolver este problema. Una de ellas es 
utilizar caracteres que no sean gráficos para funciones en donde se 
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requiere la detección de la pantalla y reservar los otros caracteres gráficos 
exclusivamente para efecto decorativo. Ello parece constituir un desperdi- 
cio de los excelentes recursos gráficos del Spectrum. 

El segundo método consiste en mantener en memoria un mapa exacto 
de lo que se visualiza en la pantalla y utilizar esta representación para la 
detección de las colisiones en lugar del mapa de pantalla visualizado. Este 
es fundamentalmente el procedimiento utilizado en el programa del Trono 
de Camelot. Sin embargo, para una visualización de pantalla y/o mapa 
grande dicho método puede ser muy consumidor de memoria y puede ser 
lento de procesar. Asimismo, parece ser poco elegante para mantener 
simultáneamente dos representaciones de la misma información, si ello 
puede evitarse. 

El tercer método es utilizar los atributos de las posiciones de pantalla 
como indicadores del estado del protagonista de la aventura. Con ocho 
colores de INK, ocho colores de PAPER, dos estados intermitentes y dos 
estados brillantes, se dispondrá de 256 combinaciones posibles que pueden 
ser Objeto de prueba (¿reconoce el número mágico?). 

Por ejemplo, supongamos que el mapa visualizado es de una zona 
silvestre que contiene bosques, montañas, un lago y poblaciones. Podemos 
utilizar los gráficos definidos por el usuario para dibujar este mapa, 
haciéndole visualmente tan interesante como sea posible. Si, al realizar su 
impresión, nos aseguramos de que los bosques utilicen el color INK verde, 
las montañas el color magenta, los lagos el color azul y las poblaciones el 
color negro, podremos utilizar el atributo de la posición de la pantalla 
actual del protagonista para controlar el programa. Lo mismo que en el 
caso del trono de Camelot, el bucle principal desplazó al jugador (con el 
cambio de la variable denominada “posición”) y luego utilizó los 
“atributos”” de esa posición que se habían codificado en el programa para 
determinar qué rutinas irían a continuación, podremos desplazar de forma 
continuada, el protagonista del jugador a través de la pantalla y utilizar 
sus atributos para controlar el resto del programa. 

Ello se realiza utilizando ATTR(x,y). Esta función proporciona un 
número que codifica el estado actual de cualquier posición de pantalla 
(qué color INK tiene, qué color PAPER tiene, si es brillante o no y si es 
intermitente Oo no). En el presente ejemplo, estamos interesados por el 
color de INK; esto es, el margen de números del 0 al 7. En consecuencia 
para decodificar el número proporcionado por ATTR debemos reducir el 
número a un valor inferior a 8. Por consiguiente, tenemos que hacer el 
cálculo siguiente: 


. SIEL NUMERO ES MAYOR QUE 128, RESTAR 128 

. SIEL NUMERO RESULTANTE ES MAYOR QUE 64, RESTAR 64 
. SIEL NUMERO RESULTANTE ES MAYOR QUE 32, RESTAR 32 
. SIEL NUMERO RESULTANTE ES MAYOR QUE 16, RESTAR 16 
. SI EL NUMERO RESULTANTE ES MAYOR QUE 8, RESTAR 8 


QU un 
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7.—Williams 


(Como veremos en el caso de la Busca del Tosoro, no necesitamos llegar a 
dichas longitudes en el caso especial.) 

Ello nos deja un número entre 1 y 7 que mantiene el color INK. A 
continuación, preguntamos a cuál de los cuatro colores posibles en 
nuestro mapa corresponde ese número y enviamos el control de acuerdo 
con el resultado de dicha indagación, utilizando líneas como las que se 
indican a continuación: 


IF N = 0 THEN GOSUB POBLACION 

IF N = 1 THEN GOSUB MAR 

IF N = 2 THEN GOSUB MONTAÑA 

IF N = 3 THEN GOSUB BOSQUE 

GOTO PRINCIPIO DEL BUCLE PRINCIPAL 


La parte tediosa de la utilización de los gráficos definidos por el 
usuario es realmente la de su concepción en primer lugar y la elaboración 
de las sentencias BIN y la determinación de cómo han de imprimirse. A 
continuación damos un listado de varios gráficos predefinidos para 
utilizarles en sus propios programas. Cada uno va precedido por una 
sentencia REM que explica cómo ha de realizarse la impresión. 


9000 UN SACO DE DINERO: 1 BLOQUE 
9010 BIN 00000000 
9020 BIN 00000000 
9030 BIN 00111000 
9040 BIN 00010000 
9050 BIN 00111000 
9060 BIN 01111100 
9070 BIN 01111000 
9080 BIN 00110000 


9000 REM UN ARBOL: 1 BLOQUE 
9010 BIN 01101110 
9020 BIN 11111111 
9030 BIN 00111011 
9040 BIN 00011110 
9050 BIN 00001100 
9060 BIN 00001000 
9070 BIN 00011100 
9080 BIN 01111110 


9000 REM UN GIGANTE LUCHADOR: BLOQUE 1 DE 4: IMPRI- 
MIR ESTE EN Y,X 

9010 BIN 00011111 

9020 BIN 00010011 

9030 BIN 00000011 

9040 BIN 00000011 
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BIN 00000001 
BIN 00000011 
BIN 00000111 
BIN 00000111 


REM UN GIGANTE LUCHADOR: BLOQUE 2 DE 4: IMPRI- 


MIR EN Y,X+1 


BIN 00000000 
BIN 10000000 
BIN 11000000 
BIN 10000000 
BIN 00000101 
BIN 11001111 
BIN 11100101 
BIN 10110100 


REM UN GIGANTE LUCHADOR: BLOQUE 3 DE 4: IMPRI- 


MIR EN Y+1,X 


BIN 00001111 
BIN 00001111 
BIN 00011111 
BIN 00011111 
BIN 00111110 
BIN 01111100 
BIN 01111100 
BIN 11111110 


REM UN GIGANTE LUCHADOR: BLOQUE 4 DE 4: IMPRI- 


MIR EN EN Y+1,X+1 


BIN 10011100 
BIN 10000000 
BIN 11000000 
BIN 11100000 
BIN 01100000 
BIN 01100000 
BIN 01100000 
BIN 01111000 


REM UNA CRUZ ORNAMENTAL: BLOQUE 1 DE 2: IM- 


PRIMIR EN Y,X 


BIN 00010000 
BIN 00111000 
BIN 01010100 
BIN 11111110 
BIN 01010100 
BIN 00111000 
BIN 00010000 
BIN 00010000 
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9090 REM UNA CRUZ ORNAMENTAL: BLOQUE 2 DE 2: IM- 
PRIMIR EN Y+1,X 
9100 BIN 00010000 
9110 BIN 00010000 
9120 BIN 00111000 
9130 BIN 00111000 
9140 BIN 01111100 
9150 BIN 11111110 
9160 BIN 11111110 


9000 REM CASTILLO: BLOQUE 1 DE 2: IMPRIMIR EN Y,X 
9010 BIN 01010000 
9020 BIN 01110000 
9030 BIN 01010000 
9040 BIN 01110000 
9050 BIN 01110101 
9060 BIN 01111110 
9080 BIN 11111110 


9090 REM CASTILLO: BLOQUE 2 DE 2: IMPRIMIR EN Y,X+1 
9100 BIN 00010100 
9110 BIN 00011100 
9120 BIN 00010100 
9130 BIN 00011100 
9140 BIN 01011100 
9150 BIN 11111100 
9160 BIN 11111110 
9170 BIN 11111111 


9000 REM TORRE EN RUINAS: BLOQUE 1 DE 2: IMPRIMIR 
EN Y,X 
9010 BIN 01000000 
9020 BIN 01000000 
9030 BIN 01100000 
9040 BIN 01100010 
9050 BIN 01100110 
9060 BIN 01101110 
9070 BIN 01111010 
9080 BIN 01111010 


9090 REM TORRE EN RUINAS: BLOQUE 2 DE 2: IMPRIMIR 
EN Y+1,X 

9100 BIN 01011110 

9110 BIN 01011110 

9120 BIN 01111110 

9130 BIN 01111110 

9140 BIN 11111110 


9150 BIN 11111110 
9160 BIN 11111111 
9170 BIN 11111111 


9000 REM UNICORNIO: BLOQUE 1 DE 3: IMPRIMIR EN Y,X 
9010 BIN 00000000 
9020 BIN 10000000 
9030 BIN 01000000 
9040 BIN 00100000 
9050 BIN 00111000 
9060 BIN 01111100 
9070 BIN 11111110 
9080 BIN 00001110 


9090 REM UNICORNIO: BLOQUE 2 DE 3: IMPRIMIR EN 
Y+1,X 
9100 BIN 00001111 
9110 BIN 00001111 
9120 BIN 00011111 
9130 BIN 00101000 
9140 BIN 00101000 
9150 BIN 00101000 
9160 BIN 00101000 
9170 BIN 00001000 


9188 REM UNICORNIO: BLOQUE 3 DE 3: IMPRIMIR EN 
Y+1,X+1 
9190 BIN 11110000 
9200 BIN 11111000 
9210 BIN 11111100 
9220 BIN 01010110 
9230 BIN 10010111 
9240 BIN 10010001 
9250 BIN 10010000 
9260 BIN 00010000 


10.2 Minijuegos 


Los juegos de acción rápida tienen sus atractivos y es indudable que una 
de las razones más importantes para el crecimiento de la industria de los 
ordenadores personales ha sido la popularidad de dichos juegos de 
pantalla de acción rápida. No es posible en el lenguaje BASIC escribir 
juegos de este tipo con una acción muy rápida porque el lenguaje es algo 
lento al tratarse de un lenguaje interpretado. Si dispone de un compilador 
o comprende el código de máquina, no tendrá ninguna dificultad, pero la 
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mayoría de nosotros tenemos que trabajar con la consideración de la 
lentitud del BASIC. 

Sin embargo, la velocidad no es todo. La popularidad creciente de los 
juegos de aventuras así lo indican. Podría ser digno de consideración la 
introducción de alguna acción rápida en nuestros juegos de aventuras, aun 
cuando no sea de la más alta calidad, para añadir un poco de interés de 
diferente clase a lo que inicialmente se concibió como un juego del 
intelecto. 

Si vamos a incluir un minijuego de gráficos de alguna clase, debemos 
cerciorarnos de que tiene relación con el juego principal y de que no utiliza 
una cantidad desproporcionada de espacio. El elemento de acción rápida 
debe ser una bonoficación en exceso del elemento previsto en el juego que 
representa. Una solución sería hacer que todos los combates de los 
monstruos se hagan con gráficos en tiempo real, aunque, en mi opinión, 
ha de hacerse todo lo posible porque no se produzca un desperdicio de 
todos los demás recursos disponibles para un programador de juegos de 
aventuras. 

Mucho más sencillo, aunque con el empleo de prácticamente los 
mismos principios, es una rutina de acumulación de tesoros. Una versión 
gráfica de combates de monstruos debe detener y manipular un gran 
número de variables e intentar la simulación del combate real con recursos 
limitados. En BASIC, el nivel de animación que ello requiere no es 
realmente alcanzable. Sin embargo, si simplificamos nuestros gráficos 
utilizando gráficos de bloques o bien gráficos definidos por el usuario y 
reducimos nuestros objetivos, podemos conseguir juegos de acción rápida 
bastante atractivos que se probarán en una forma limitada, agradable a la 
vista y actuando de una forma significativa en el contexto del juego total. 

Solamente se plantean dos problemas reales en los juegos de acción 
rápida: el desplazamiento de los objetos y la detección de las colisiones. 
Ambas materias ya fueron objeto de tratamiento. Dicho de forma 
esquemática, el desplazamiento de un objeto indica la impresión de un 
gráfico en una posición, el cálculo de una nueva posición, su impresión en 
la nueva posición y el borrado de la posición antigua. Si ello sucede con la 
suficiente rapidez, parecerá como si se tratara de un movimiento. La 
detección de la colisión implica la adición de varias pruebas dentro del 
bucle de movimiento para comprobar si la nueva posición está ocupada ya 
y si fuera así, quién es el ocupante. El resultado de la reunión de los dos 
objetos se calculará a continuación. Es fácil de ver la razón de que dicha 
circunstancia haga el juego más lento. Si tenemos 40 invasores, 1 arma de 
fuego, 5 misiles y 20 bombas en la pantalla entonces cada “turno” en el 
juego implica el borrado de 66 objetos, el cálculo de sus posiciones 
siguientes, la comprobación de los contactos en dichas posiciones, el 
cálculo de los efectos de cualquier contacto y la visualización de los 
resultados, con la impresión de 66 objetos en sus nuevas posiciones. Para 
que todo ello tenga lugar y que siga pareciendo natural, debe producirse 
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literalmente en un abrir y cerrar de ojos. Para BASIC, ello se parece más a 
“40 parpadeos”. 

Ahora examinaremos una versión simple en la que solamente se 
desplaza un objeto (un hombrecillo que representa al jugador) y en la que 
sólo una posición necesita comprobarse con respecto a las colisiones en 
cada turno de juego (la posición a la que el hombre se desplazará en el 
siguiente movimiento). La idea fundamental de la rutina es simple. En 
lugar de que el jugador simplemente diga “he encontrado 43 piezas de 
plata”, la rutina del tesoro le implica realmente en la recogida del dinero 
por sí mismo. Tiene un número fijo de movimientos, por lo que solamente 
puede recoger una cantidad limitada y realiza esta tarea desplazándose 
alrededor del recinto cogiendo joyas. Este es el juego de la Busca del 
Tesoro que se ilustra en la Figura 10.5. 


Busca del Tesoro 


1 CLEAR 

2 CLS 

3 LET y=10: LET x=10 

4 LET dinero=0 

5 INK 7 

10 LET x=0: LET y=0 

15 BORDER O 

20 PAPER O 

30 GO SUB 1500 

35 CLS 

40 DEF FN rO0=INT (RND*O 
45 FOR j=1 TO 2 

46 READ a$ 

50 FOR 1=0 TO 7 

55 READ a 

60 POKE USR a$+i,a 

70 NEXT 1 

80 NEXT j 

81 FOR 1=1 TO 20 

82 LET x=FN r(21)+1 

83 LET y=FN r(31)+1 

86 PRINT AT x,y; INK 7;'"4f" 
88 NEXT 1 

100 FOR 1=1 TO 12 

110 LET x=FN r(21)+1 

120 LET y=FN r(31)+1 

130 PRINT AT x,y; INK 2;"Mb" 
140 NEXT 1 

150 FOR i=1 TO 5 

160 LET x=FN r(21)+1 

170 LET y=FN r(31)+1 

180 PRINT AT x,y; INK 5;" Me" 
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190 NEXT 1 

200 FOR i=1 TO 30 

210 LET x=FN r(21)+1 

220 LET y=FN r(31)+1 

230 PRINT AT x,y; INK 4;"We" 

240 NEXT 1 

490 DATA "Cc" 

500 DATA BIN 00011000 

510 DATA BIN 01111110 

520 DATA BIN 01111110 

530 DATA BIN 11111111 

540 DATA BIN 11111111 

550 DATA BIN 01111110 

560 DATA BIN 01111110 

570 DATA BIN 00011000 

580 DATA''p" 

590 DATA BIN 00111000 

600 DATA BIN 00111000 

610 DATA BIN 00111000 

620 DATA BIN 00010000 

630 DATA BIN 01111100 

640 DATA BIN 00010000 

650 DATA BIN 00101000 

660 DATA BIN 01001000 

890 LET y=10: LET x=10 

895 FOR 1=1 TO 100 

900 LET a$=INKEYS: IF a$=""' THE 
N GO TO 900 

905 LET p=x: LET q=y 

910 IF a$="5'" THEN LET x=x-1 

920 IF a$="6'" THEN LET y=y+1 

930 IF a$="7" THEN LET y=y-1 

940 IF a$="8'" THEN LET x=x+1 
950 IF y>21 THEN LET y=21 
960 IF x>31 THEN LET x=31 
970 IF x<0 THEN LET x=0 

980 IF y<1 THEN LET y=1 

985 IF SCREENS (y,x)="*"" THEN 
LET x=p: LET y=q 

990 PRINT AT q,p;" ” 

995 PRINT AT 0,1; INVERSE 1;''D1 
nero "¿dinero 

996 PRINT AT 0,19; FLASH 1;"Ti 
empo dejado " ¿100- 

1010 IF ATTR (y,r)=5 THEN LET 
dinero=dinero+10: FOR b=1 TO 5: 
BEEP .001,b*5: NEXT b 

1020 IF ATTR (y,x)=2 THEN LET 
dinero=dinero+5: FOR b=5 TO 9: 
BEEP .01,b*3: NEXT b 
1025 IF ATTR C(y,r)=4 THEN LET 
dinero=dinero+1: FOR b=5 TO 10: 
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BEEP .01,b*3: NEXT b 

1026 PRINT AT y,x; INK 3;"*" 

1027 BEEP .01,1 

1030 NEXT 1 

1100 FOR J=1 TO 100 

1105 INK FN RC7) 

1106 PAPER FN R(7) 

1107 PRINT AT 10,9;"FUERA DE TI 

EMPO" 

1110 NEXT J 

1120 PAPER O: INK 7 

1199 STOP 

1500 LET A$="BUSCA DEL TESORO" 

1510 FOR I=1 TO LEN (AS) 

1520 LET R=FN R(7) 

1525 LET S=FN R(7): IF S=R THEN 
GO TO 1525 

1530 PRINT AT 1+2,1+6; INK R; PA 

PER S;ASCI) 

1550 NEXT I 

1560 PAUSE 100 

1570 CLS 

1600 PRINT AT 2,2;'"Tiene que re 
coger las joyas",” para aumentar 
su riqueza" 

1610 PRINT AT 5,4;"Las joyas azu 
les valen",'" 10 piezas de plata" 
1620 PRINT AT 8,4;"Las joyas rojJ 

as valen",' 5 piezas de plata" 
1630 PRINT AT 11,4;"Las joyas ve 
rdes valen"," 1 pieza de plata" 

1640 PRINT AT 15,4;'Controla el 

movimiento”,'' utilizando las tec 

Las del cursor." 

1650 PRINT AT 18,2;"No es posibl 

e pasar”,'" a traves de las tramp 

as (H) " 

1660 PRINT + 1;'"Pulse una tecla 

de cursor para comenzar" 

1690 PAUSE 1000 

1699 RETURN 

1999 STOP 


Figura 10.5 


Las joyas tienen tres valores diferentes. Ello introduce un elemento 
limitado de estrategia: Dada una cantidad limitada de tiempo, cuál es el 
mejor camino para recoger la mayor cantidad posible de las joyas de alto 
valor (color cyan) mientras se pasa a través del mayor número posible de 
las agrupaciones mayores de joyas con las denominaciones más reducidas. 
La puntuación máxima sería de 140 piezas de plata y una puntuación 
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media sería de 60. Estas puntuaciones pueden variarse fácilmente cam- 
biando los valores de las joyas (líneas 1010, 1020 y 1025) o bien 
cambiando las cantidades de joyas (líneas 100, 150 y 200). 

Con una ligera complicación hay varias trampas, que son simplemente 
obstáculos que el jugador no puede atravesar. Si deseamos incrementar la 
dificultad del juego, podríamos añadir más trampas (línea 81) o podría- 
mos imponer una sanción si se cayera en una trampa (la supresión de 
alguna parte del tesoro o una reducción en el número de turnos restantes). 

El programa actúa de una forma bastante simple y se da aquí como un 
juego completo, por lo que se puede introducir por el teclado y ejecutar sin 
incorporación en otro juego. En primer lugar, los títulos y las instruccio- 
nes se imprimen en la subrutina 1500. Las líneas 1500 a 1550 realizan la 
impresión del título como una serie diagonal de bloques de colores 
aleatorios. Tal como está el programa, los colores son del tipo PAPER, 
con las letras en negro. Sin embargo, si el cero en las líneas 1530 se cambia 
a R, la coloración en cada bloque será un color INK aleatorio que es 
diferente del color PAPER (la línea 1525 comprueba que son diferentes). 

La línea 1560 establece la seguridad de que el jugador tiene tiempo para 
icer el título y la línea 1600 a 1660 realiza la impresión de las instruccio- 
nes. Ha de tenerse presente que las instrucciones se han colocado en la 
pantalla para hacer máxima la utilización del espacio y hacerles más 
fácilmente legibles. Asimismo, obsérvese la orden en la línea 1660 que 
realiza la impresión en la parte inferior de dos líneas de la pantalla (lo cual 
es imposible en condiciones normales). Esta no suele ser una buena idea, 
pero en este caso es admisible habida cuenta de que se borra la pantalla 
antes de que se haga ninguna otra cosa. 

La subrutina retorna a la rutina principal y, entonces, la línea 45 a 80 
efectúan la lectura de los datos para dos gráficos definidos por el usuario, 
que son la joya que se mantiene como gráfico (c) y el hombrecillo que se 
mantiene como gráfico (c). Obsérvese que no solamente las sentencias 
BIN se mantienen en las sentencias DATA sino que también lo están las 
direcciones para cada carácter (líneas 490 a 660). 

Las líneas 100 a 240 imprimen ahora la visualización, eligiendo de 
forma aleatoria, una posición PRINT AT y colocando primero trampas y 
luego, joyas de diferentes colores en la pantalla. Las líneas 895 a 1110 
constituyen en bucle principal, que se ejecuta cien veces y que es el “límite 
de tiempo” del jugador. La línea 910 realiza la búsqueda de la entrada 
procedente del teclado, mientras que la línea 920 establece p y q para la 
posición actual del hombre. La línea 910 establece los nuevos valores para 
la posición de acuerdo con la tecla pulsada (téngase presente que, aunque 
el jugador estime que está pulsando “teclas del cursor”, está probando 
realmente los números 5 a 8). Las líneas 950 a 980 aseguran que el hombre 
no intente salir de la pantalla comprobando que x e y (que son las 
coordenadas que el hombre imprimirá) no están fuera de los límites de la 
pantalla. 
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La línea 985 utiliza SCREENS para comprobar la naturaleza de la 
posición a la que el hombre desea trasladarse en la forma normal. Si la 
posición es una trampa, x e y son objeto de reposición a sus valores 
antiguos, mantenidos en p y q. La posición anterior es objeto de 
reimpresión con un espacio por la línea 990. 

Las líneas 995 y 996 imprimen el número actual de turnos de juego que 
quedan y las piezas de plata que se han conseguido. Obsérvese que el 
indicador “tiempo que queda” parpadea con la intención de aumentar la 
tensión del juego. Las líneas 1010 a 1025 prueban las joyas en la posición 
actual por los medios anteriormente descritos para la comprobación de los 
atributos (ATTR) de la nueva posición. Ello es así porque las joyas son 
gráficos definidos por et usuario y, por consiguiente, invisibles para 
SCREENS. Esta es también la razón por la que el color PAPER es negro. 
Todas las clases de valores de atributos (ATTR) podrían ser objeto de 
prueba, pero como el negro corresponde al cero y por ello no añade nada a 
este valor, los números que vamos a probar pueden ser pequeños y simples 
(solamente los números de atributos de los colores INK para rojo, verde y 
cyan). 

Si se encuentra un atributo particular, la variable “dinero” se incre- 
mentará en la cantidad correcta y sonará una escala acústica rápida 
(BEEP) para indicar dicha circunstancia. A continuación, el hombre es 
objeto de impresión en su nueva posición y un tono de corta duración 
(BEEP) indica que se ha desplazado y que, por consiguiente, ha transcurri- 
do un turno de juego. Dicho tono ha de ser rápido porque el sonido del 
Spectrum disminuye la velocidad del programa, en una magnitud notable, 
puesto que interrumpe la ejecución del programa, a diferencia con otros 
sistemas que procesan el sonido sin interferir con la ejecución de la rutina 
principal. 

El bucle se sigue ejecutando hasta que hayan transcurrido cien turnos 
de juego, en cuyo momento las líneas 1100 a 110 indican con colores 
aleatorios parpadeantes que el juego ha concluido; entonces, la línea 1999 
detiene (STOP) la ejecución. 
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MICROCOMPUTADORAS 
11 EN JUEGOS SIN SU EMPLEO 


11.1 Programas de asistencia a juegos (GAPs) 


Para utilizar una microcomputadora en un juego de aventuras no es 
necesario ejecutar el juego en dicha máquina. Como se indicó en el 
Capítulo 1, muchos juegos de aventuras se ejecutan como juegos de ta- 
bleros o de sobremesa. Los más conocidos de estos últimos son los de 
Mazmorras y de Dragones (un juego de fantasía) y Viajero (un juego de 
ciencia ficción). Hay muchas ventajas en la ejecución de las versiones de ta- 
bleros o de sobremesa, de juegos de aventuras, puesto que el juego puede 
ser mucho más complejo y fluido que su equivalente en microjuegos (los 
juegos de Mazmorras y de Dragones tienen más de 1.000 páginas de 
“reglas””); las miniaturas y los contadores pueden hacer el juego más 
atractivo desde el punto de vista físico y visual; el juego tiene más de 
actividad social, con el énfasis sobre el desempeño del papel funcional y, al 
mismo tiempo, podrá conseguirse un mayor grado de realismo y de 
detalle. Es posible que, a la larga, los juegos de aventuras para microcom- 
putadoras sustituirán a estos juegos pero ello no será por muchos años 
hasta que se haya desarrollado, en gran medida, la memoria, los gráficos, 
el control interactivo y la “inteligencia”. 

Sin embargo, las microcomputadoras pueden añadir una espectacular 
nueva dimensión a la mayor parte de los juegos de sobremesa y de 
tableros. Muchos jugadores de estos tipos de juegos utilizan sus micro- 
computadoras para ejecutar programas de asistencia a juegos (que se 
conocen en su forma abreviada de GAPs). Se trata de programas que se 
refieren a algunos de los aspectos mecánicos, tediosos o complejos del 
juego, lo que permite a los jugadores disfrutar del juego sin preocuparse de 
sus mecanismos. Ejemplo son los GAPs que tratan los detalles complejos 
del combate entre dos ejércitos en un juego estratégico o que generan 
mapas de estrellas como juegos tales como el del Viajero. 

Si le agradan los microjuegos de aventuras, es casi seguro que le 
gustarán las versiones de sobremesa originales, por lo que esta sección se 
refiere a dos GAPs que le podría agradar incorporar a dichos juegos. 
Naturalmente, cualquier programa que se pueda utilizar en un juego de 
sobremesa también se puede emplear en un juego de aventuras ejecutado 
completamente en una microcomputadora, por lo que siempre podría 
utilizar estas ideas como la base de sus propios programas de aventuras. 
El inconveniente principal es que las rutinas basadas en estas ideas pueden 
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utilizar una cantidad desproporcionada de memoria, porque tratan 
aspectos muy detallados de los juegos. Por consiguiente, si las utiliza en un 
microjuego de aventuras, dicho juego se hará bastante desequilibrado 
puesto que no dispondrá de mucho espacio para las demás rutinas. A no 
ser que tenga una máquina de 16 bits o una microcomputadora como la 
Newbrain que pueda direccionar una gran cantidad de memoria mediante 
la paginación, no dispondrá de suficiente memoria para utilizar dichas 
rutinas en los microjuegos de aventuras. Sin embargo, hay otra solución 
que se tratará en la siguiente sección y en ella se utiliza una serie de 
programas como una sola aventura, como en los juegos desarrollados por 
correo. 

Para aprovechar bien el tiempo de programación, un GAP debe 
realizar algo bastante mejor que como se podría hacer de forma manual o 
bien, debe ahorrar tiempo. Los GAPs se escriben para ahorrar tiempo en 
los aspectos de juegos que resultan tediosos. De estos últimos, los más 
frecuentes son los que corresponden a las rutinas que generan caracteres 
para juegos de sobremesa. En condiciones normales, un juego de desempe- 
ño de papel necesita una hora o dos de antemano mientras se efectúa la 
tirada de varios dados para establecer las variables que forman el 
protagonista, o los protagonistas, que ejecutan el juego. Como dicho 
protagonista puede tener más de 20 de dichos valores, con cada uno de 
ellos aceptando o dependiendo de los demás, ello puede suponer una gran 
cantidad de trabajo tedioso. Habida cuenta de que el proceso básico es 
generar una serie de números aleatorios y establecer una lista de valores de 
acuerdo con la forma en que dichos valores aleatorios se han de 
interrelacionar, resulta fácil concebir un diagrama de flujo para este 
proceso y luego, proceder a su codificación. 

Cada juego tiene su propia versión de este proceso, por lo que hay 
pocas posibilidades de uso para un programa en este caso. Sin embargo, 
como muchos de estos juegos requieren una serie compleja de números 
aleatorios para su establecimiento, la siguiente rutina general puede ser de 
utilidad. Es un generador de números aleatorios estándar el dispositivo 
que permite la selección de las probabilidades lineales en un margen 
elegido u otras curvas probabilísticas (escogidas seleccionando un número 
de dados con cualquier número de caras que no sean uno). En la Figu- 
ra 11.1 se ilustra dicha rutina. 


5 CLS 

10 DEF FN r()=INT  (RNDx*P)+1 

15 CLS : PRINT "Quiere un nume 
ro en un intervalo lineal 

(1) o un conjunto de tiradas d 
e dados (2)?" 

20 LET x$="Para otro juego de 
tiradas de datos teclear 1" 
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24 LET YS="Para cambiar parame 
tros teclear 2" 

28 LET Z$=Para finalizar tecle 
ar 3" 

30 INPUT A: FI A<1 OR A>2 THEN 

CLS : GO TO 15 

40 IF A=2 THEN GO TO 500 

95 CLS 

100 CLS : PRINT ' Cual es el nu 
mero mas bajo en el intervalo?" 

110 INPUT B 

115 CELS 

120 CLS : PRINT ” Cual es el nu 
mero mas alto en el intervalo?" 
130 INPUT C 

135 CLS 

136 PRINT AT 0,9;'"MARGEN LINEAL 


137 PRINT AT 2,0;"Alto 
Bajo" 
138 PRINT AT 3,2;C: PRINT AT 3, 


140 PRINT AT 10,6;"El numero es 
"INT (RNDx(C+1-B)+B 

150 PRINT AT 16,0;"Para otro num 
ero teclear 1" 

160 PRINT YS$ 

170 PRINT Z$ 

180 INPUT A 

185 IF A<1 OR A>3 THEN CLS : G 
O TO 150 

186 CLS 

190 IF A=1 THEN GO TO 135 

200 IF A=2 THEN GO TO 10 

210 IF A=3 THEN GO TO 999 

500 CLS : PRINT "Cuantas caras 
tiene su dado?"' 

510 PRINT "Sirvase introducir u 
n numero entre 2 y 100" 

520 INPUT P 

530 LET a=INT (A): IF<A 2 OR A> 
100 THEN CLS : GO TO 500 

540 CLS . PRINT "Cuantas tirada 
s de su dado con ";P;'" caras?" 
550 INPUT B 

560 LET B=INT (B): IF B<1 OR B> 
1000 THEN PRINT "Solamente se pe 
rmite de 1 a 1000 tiradas ": GO 
TO 540 

570 CLS : PRINT "Quiere las tir 
adas '",''impresas por separado(1) 


, Oo reunidas  (2)?" 
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580 INPUT C 

590 LET C=INT (C): IF C<1 OR C> 
2 THEN CLS : GO TO 570 

600 IF C=1 THEN GO TO 700 

605 LET D=0: LET E=0 

610 FOR I=1 TO B 

620 LET E=FN RO 

630 LET D=D+E 

640 NEXT I 

645 CLS 

650 PRINT 'Su numero es ";D 
660 PRINT X$ 

670 PRINT Y$ 

680 PRINT Z$ 

690 INPUT A 

692 IF A<1 OR A>3 THEN CLS : G 
O TO 660 

694 IF A=1 THEN GO TO 605 

695 IF A=2 THEN GO TO 10 

696 IF A=3 THEN GO TO 999 

700 LET D=0 

702 CLS 

705 FOR I=1 TO B 

710 LET D=FN (R): PRINT "Usted 
tira ";D 

720 NEXT 1 

750 PRINT X$ 

760 PRINT YS$ 

770 PRINT Z$ 

790 INPUT A 

792 IF A<1 OR A>3 THEN CLS : G 
O TO 750 

794 1F A=1 THEN GO TO 700 

795 IF A=2 THEN GO TO 10 

796 IF A=3 THEN GO TO 999 

999 STOP 


Figura 11.1 


Muchos otros aspectos de los juegos de FRP son esencialmente 
aleatorios, aunque con algunos valores fijos, por lo que esta rutina puede 
ser de utilidad para muchos aspectos del juego, tales cómo la determina- 
ción de los números de recintos en una mazmorra, el número y la clase de 
monstruos en una posición particular, los hechizos disponibles para un 
mago particular, las naves espaciales en una flota, las flotas disponibles 
para un ejército. Para estos elementos no se precisan artificios de 
programación especiales, sino simplemente una estructuración esmerada. 
No obstante, el programa para cualquiera de ellos será diferente para cada 
sistema de juego. Por regla general, es preferible generar primero todos los 
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números aleatorios necesarios y retenerlos en un array o un fichero de una 
cierta clase. 

Hay algunas rutinas generales que pueden ser de utilidad para muchos 
juegos del desempeño del papel. Un ejemplo lo constituye la rutina de 
generación de nombres que se da en el Capítulo 7. Otro ejemplo de rutina 
podría ser de uso no solamente en la ejecución de los juegos, sino también 
para estimular ideas de todas clases; se trata de un generador de ideas que 
crea ideas nuevas para su empleo como la base de juegos o de escenarios, 
tal como el que se muestra en la Figura 11.2. 


50 REM PROGRAMA DE IDEAS DE FA 
NTASIA 

89 REM INICIALIZACION 

90 LET na=30: LET aa=30: LET y 
a=30 

95 LET VW=0 

100 DIM n$(na,11): DIM NCNA): D 
IM a$(aa,11): DIM ACAA): DIM v$( 
va,14): DIM V(VA,2) 

110 GO SUB 1000 

115 DEF FN r(x)=INT (RNDx*x) +1 
120 LET indicador=0 

129 REM COMIENZO DE BUCLE PRINC 
IPAL 

130 PRINT "LA "; 

140 LET T=FN RC(NA) 

145 LE VW=0 

150 IF INDI<>0 THEN GO SUB 200 
O : REM COMPROBAR QUE NA Y VA CO 
NCUERDAN - PROPORCIONA VV=1 SI 
NO ES ASI 

160 IF VWY=1 THEN GO TO 140 
170 LET R=FN R(3)-1 

180 IF R<2 THEN GO TO 300 

190 FOR 1=1 TOR 

200 LET S=FN RCAA) 

210 IF A(S)=NC(T) THEN GO TO 22 
0 

215 IF A(S)=2 THEN GO TO 220 
218 GO TO 200 

220 LET C$=AS(S): GO SUB 2500 
230 NEXT I 

300 LET C$=N$(T>): GO SUB 2500 
310 LET R=FN R(3) 

320 IF INDIC<R THEN GO TO 500 
330 PRINT "." 

340 PRINT 

350 LET INDIC=0 

360 GO TO 130 
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361 REM FINAL DEL BUCLE PRINCIP 


500 LET U=FN R(VA) 
510 IF V(U,1)=NCT)> THEN GO TO 


520 IF V(U,1)=2 THEN GO TO 600 
530 GO TO 500 

600 LET C$=V$(U): GO SUB 2500 
610 LET INDIC=INDIC+1 

620 GO TO 130 

999 REM LECTURA DATOS EN ARRAYS 
1000 FOR I=1 TO NA 

1010 READ N$C1),NCI) 

1020 NEXT 1 

1030 FOR 1=1 TO AA 

1040 READ A$(I),ACI) 

1050 NEXT 1 

1060 FOR I=1 TO VA 

1070 READ V$(1),V(1,1),V(1,2) 
1080 NEXT 1 

1100 RETURN 

2000 REM COMPROBAR CONCORDANCIA 
DE NOMBRES Y VERBOS 

2010 IF V(U,2)=2 THEN RETURN 
2020 IF NCT)=V(U,2) THEN RETURN 
2030 LET VW=1 

2040 RETURN 

2499 REM ELIMINAR ESPACIOS DE DA 
TOS 

2500 LET B$=C$ 

2505 FOR K=1 TO LEN (CS) 

2510 IF CS(K)<>" "" THEN LET J=K 
2520 NEXT K 

2540 PRINT B$(1 TO J);" "; 

2599 RETURN 

5000 DATA "CASA",0,'DRAGON",1,"G 
NOMO",1,'"DUENDE",1,"'LLAVE",0 ,"P 
IEDRA",0,"LIBRO",0,'"PERGAMINO”,0 
,"POCION",0,"ESCLAVO",1 

5010 DATA "ARBOL",1,'"SOMBRERO",0 
,"CHAQUETA"',0,"TRAJE",0,'CASCO", 
0,'"CORONA",0,"PAJARO",1,""PERRO", 
1, "HALCON", 1,,''MANZANA",0 

5020 DATA “CABALLO",1,"ESCARABAJ 
0",1,"NIEBLA",1,"DIABLO",1,"HOMB 
RE",1,""ENANO"",1,""ELFO",1,'"MUJER" 
1,1,"0GRO"",1,''MONSTRUO",1 

5100 DATA “"FRIO",2,"ESTUPIDO",1, 
"ACERO",0,"ORO",2,"COBRE",0,'"'NEG 
RO",2,""AZUL",2,"BLANCO"',2,""VERDE 
"72, "AMARILLO",2 

5110 DATA "INTELIGENTE",2,"LISTO 
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",2,"HIERRO”,2,"MADERA",0,"ZAFIR 
0",0,"FUERTE",1,"DEBIL",1,"VAGO" 
,1,"NECIO",1,"ROTO",0 

5120 DATA "SANTO",2,"PERVERSO",2 
,"BLANDO"",2,"'BEODO",1,""ASUSTADO"' 
,1,"HAMBRIENTO",1,"DURO",2,"VIEJ 
0",2,"FEO",2,"ALGIDO",2 

5200 DATA "ENEMIGO DE”,1,1,""0DI 
ADO POR",2,1,"PERSEGUIDOR",1,1," 
OCULTADOR",2,2,"'ODIANTE",1,2,"HA 
CEDOR DE"1,0,"HECHO POR",0,1,"P 
ROPIEDAD DE",0,1,"'VIVIENDO POR", 
2,1,"TEMEROSO DE",1,2 

5210 DATA "ABORRECIDO POR”,2,1," 
MUERTO POR",1,2,'""ENAMORADO DE",1 
,1,'"TOMADO DE",2,1,"CAZADO POR”, 
1,1,"ODIADO POR",2,1,"'OCULTO POR 
"72,2, "AMIGO DE'",1,1,"ASESINO DE 
",1,1,"NATIVO DE",0,1 

5220 DATA "ESCLAVO DE",1,1,"OCUL 
TO DE'",1,1,"'ROBADO DE",0,1,""C0G1 
DO POR",1,1,''MAESTRO DE",1,2,"AD 
ORADO POR",2,1,"ENCANTADO POR",2 
,2,"AMIGO DE",1,1,"'ENCONTRADO CE 
RCA",2,2,"DESCUBIERTO POR",2,1 


Figura 11.2 


Dicho programa tiene algunos de los elementos de la inteligencia 
artificial; esto es, simula creatividad, generando nuevas ideas tal como lo 
podría hacer un ser humano (por ejemplo, generando los mapas de mente 
indicados en el Capítulo 3). Sin embargo, el programa no realiza la 
evaluación de ninguna de las ideas. Para poder hacerlo requeriría una 
enorme base de datos del conocimiento sobre lo que era práctico o 
deseable en el mundo real. La creatividad en términos humanos es una 
cuestión de determinar nuevos enlaces entre elementos existentes y ello es 
lo que hace este programa. El usuario ha de evaluarles, decidir cuáles de 
ellos podrían dar lugar a juegos o escenarios de utilidades y cuáles son 
triviales o sin posibilidades de uso práctico. 

El valor de un programa como el anterior depende de su base de datos. 
La versión que incurrimos aquí trata de crear nuevas ideas de fantasía, 
pero diferentes bases de datos se podrian utilizar para otros tipos de 
trazado o de escenario, tal como un mundo de ciencia ficción o un 
ambiente del Oeste Americano. Otras bases de datos, bastante más 
distantes del tipo que se suele encontrar en un juego de aventuras, podrían 
incluir diferentes clases de relaciones humanas desde el punto de vista 
social o político, o bien, las clasés de relaciones típicas de los melodramas 
televisivos o cualquier situación en la que dos elementos estén enlazados 
de alguna manera. 
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El programa actúa elaborando frases con nombres que se refieren a 
objetos/criaturas, seres y luego, enlazando dos o más de dichas frases 
mediante una relación verbal de alguna clase. Para evitar construcciones 
deficientes desde el punto de vista gramatical, se incorporan algunas 
limitaciones a la base de datos. Sin embargo, todas las posibles relaciones 
son correctas desde el punto de vista semántico, aunque algunas puedan 
parecer un poco (irregulares). La base de esta corrección es los números 
incluidos en las sentencias DATA después de cada palabra o frase. Todos 
los nombres y adjetivos tienen un código de número único y todas las 
clases de verbos tienen dos códigos de números. El código O significa que 
la palabra es inanimada, un 1 significa que es animada, y un 2 significa 
que podría ser una u otra cosa. Las frases de verbos tienen dos códigos 
porque van precedidas por una palabra que puede ser animada o 
inanimada y van seguidas por la misma opción. Así, por ejemplo, las 
frases “odiado por” debe ir seguida por una frase animada, porque 
solamente las cosas animadas pueden odiar, pero puede ir precedida o una 
frase animada o inanimada, pues ambas clases de cosas son capaces de 
odiar. Su código es, pues, “2,1”. 

Si va a diseñar su propio programa GAP, es preferible que comience 
con un aspecto pequeño del juego que se pueda aislar del resto y que 
comprenda bastante bien. Se percatará por ahora, que el motivo para ello 
es que dichos programas tienen muchas más características que las que se 
prevé y que, por tanto, exige una planificación muy cuidadosa. Siempre se 
tiene la tentación de comenzar con algo muy complejo, tal como un 
sistema de combate de juego. Aunque es cierto que estos sistemas suelen 
ser “hechos a medida” para su adaptación a las microcomputadoras, no es 
menos cierto que encontrará más dificultades de las previstas, por lo que 
es probable que acabe por abandonar el proyecto sin acabarlo si es que se 
empeñara de abarcar más de lo que puede “digerir”. 

Por consiguiente, es mucho mejor empezar con algo elemental de 
modo que pueda aprender cómo hacerlo en la práctica sin llegar a tener 
frustaciones o cansancio; por ejemplo, un programa de juegos de dados o 
un programa que genere los ejércitos en un juego bélico. Aunque estos 
últimos son relativamente “autónomos” no obstante podrían ser de 
utilidad en un juego. Una vez que hayan desarrollado, de forma satisfacto- 
ria un programa GAP sencillo como el anterior, puede comenzar a 
trabajar con programas más completos. Estos últimos se deben abordar 
por secciones. Lamentablemente, la mayor parte de los juegos se pueden 
describir como algoritmos o diagramas de flujo, por lo que la naturaleza 
del problema no suele ser demasiado dificil de especificar. Sin embargo, es 
preciso cerciorarse de que ha elaborado todas las etapas de la descripción 
antes de que comience la tarea de la codificación o, de no ser así, se 
encontrará con que no ha permitido la inclusión de todos los detalles 
intrincados de los juegos de tableros. Incluso el juego de Monopoly es 
bastante complejo. 
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11.2 Juegos de aventuras por correo 


Otra forma de jugar estos juegos es por correo. Acaso ello parezca 
extraño, pero muchos jugadores toman parte actualmente en campañas 
postales de una clase o de otra, tal como juegos bélicos, juegos de ciencia 
ficción o juegos de aventuras fantásticas, así como en otros muchos juegos 
tradicionales. Los juegos de ajedrez y de tipo diplomático también tienen 
lugar por esta vía postal. 

Las ventajas y desventajas de los juegos por correo son obvias. Por una 
parte, es una buena manera de encontrar jugadores interesados; no hay 
necesidad de preparar reuniones ni de hacer cálculos o horarios complica- 
dos para que todos los juegadores puedan estar en el mismo lugar al 
mismo tiempo; cada jugador tiene mucho tiempo para calcular su 
movimiento; un gran número de jugadores puede participar en un solo 
juego (lo que resulta imposible en una sala de estar normal); aspectos de 
las campañas/aventuras tales como la sorpresa, el movimiento oculto, el 
espionaje, la inteligencia, la moral, el descubrimiento de elementos 
mágicos, el hallazgo de secretos poderosos, la reunión de “nuevos” 
personajes O razas o el desplazamiento a un universo desconocido se 
pueden tratar de una forma realista en lugar de hacerlo de una manera 
artificial. Por otra parte, el juego por correo (o PBM como se le suele 
conocer en el mundo anglosajón) suele traer consigo unas fechas límite 
escritas para el envío de los movimientos, escasez de contacto directo entre 
los jugadores, una gran tarea administrativa por parte de la persona que 
actúa como árbitro y un cierto grado de inflexibilidad. Asimismo, los 
juegos pueden durar meses e incluso años en lugar de horas o días para su 
terminación (algunas personas consideraría esta circunstancia como una 
ventaja y otras como una desventaja). 

Puede participar en dichos juegos sin necesidad de una computadora. 
De hecho, la mayor parte de los juegos PBM no implican el empleo de una 
microcomputadora. Los juegos PBM moderados por computadoras es un 
fenómeno muy reciente, pues los árbitros y los dirigentes de los juegos se 
han percatado de que la computadora se puede encargar de realizar gran 
parte del trabajo tedioso en dicho juego y puede hacer que dichos juegos 
sean más interesantes y variados. Por regla general, solamente el árbitro o 
coordinador, en un juego PBM es la persona que utiliza la microcomputa- 
dora y los jugadores se dedican a comunicarse con el árbitro por correo y 
por teléfono en la forma habitual. En cada turno de juego, cada jugador 
recibe información por parte del árbitro sobre los resultados de los 
movimientos anteriores y luego, elabora el siguiente movimiento, lo 
escribe y lo envía al árbitro antes de la fecha límite. El árbitro introduce 
este movimiento en su microcomputadora como si se tratara de datos 
para un programa, o una serie de programas, la microcomputadora 
calcula los resultados y a continuación, el árbitro envía dichos resultados a 
los jugadores. Sin embargo, sería posible que dichos juegos se desarrolla- 
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ran completamente con el empleo de la microcomputadora, siendo 
comunicados los movimientos y los resultados correspondientes mediante 
intercambio de casetes o de discos o incluso se podrían transmitir 
directamente a través de líneas telefónicas utilizando acopladores acústi- 
cos O modems. 

Nos concentraremos en el juego más simple constituido por una 
microcomputadora, un árbitro y varios jugadores. Hay dos diferencias 
fundamentales entre esta disposición y el juego de aventuras para 
microcomputadora habitual. En las clases de juegos descritas en los 
Capítulos 1 a 10 es normal que sólo un jugador participe en el juego cada 
vez. En los juegos de PBM, el programa ha de tratar la entrada simultánea 
por parte de varios jugadores. Ello trae consigo varias dificultades de 
programación. 

En segundo lugar, en un microjuego interactivo, la velocidad de 
respuesta es un factor importante. Cualquier retardo de más de uno o dos 
segundos, mientras se están procesando las instrucciones de un jugador, 
lleva a la frustración y al aburrimiento con respecto al juego en conjunto. 
En los juegos de PBM, la velocidad de respuesta no es tan importante. 
Naturalmente, la microcomputadora ha de calcular todos los resultados 
bastante antes de la fecha límite para permitir al árbitro escribir a los 
jugadores a tiempo pero la ejecución del programa podría tardar horas o 
días entre la entrada y la salida sin producir ningún problema. Lo anterior 
permite varias técnicas de programación que no suelen ser de utilidad para 
el programador de juegos de aventuras. Dichas técnicas comprenden: 


1. Procesamiento de entrada de lenguaje natural 

2. Producción de salida del lenguaje natural variada 

3. Un alto grado de complejidad en los sistemas de normativas (por 
ejemplo, combate, magia, etc.) 

4. Grandes bases de datos almacenadas en casete o disco (por ejemplo, 
aventuras con miles en lugar de centenares de posiciones) 

5. Interacción de diferentes clases de juegos (por ejemplo, aventuras, 
juegos de gráficos y juegos bélicos estratégicos pueden ser objeto de 
combinación) 

6. Programas descompuestos en varias etapas o secciones para evitar 
limitaciones de memoria de la microcomputadora 


Dicho de otro modo, la aventura de PBM proporciona el alcance 
máximo en diseño, contenido y realización de una aventura. El programa- 
dor ya no está limitado a la capacidad de memoria RAM de la microcom- 
putadora, ni a las formas especificadas de la exigencia de entrada y de 
salida de los juegos interactivos, ni a las limitaciones de la programación 
con miras a una VDU (unidad de presentación visual) constantemente 
atractiva y actualizada. 

No obstante, hay algunas otras consideraciones preliminares. Con 
miras a ejecutar de forma eficiente un juego de PBM es conveniente 
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disponer de una impresora (y preferiblemente una que tenga alguna forma 
de salida de gráficos) y unidades de disco o alguna otra forma de 
almacenamiento masivo. En principio, un juego de PBM puede actuar sin 
alguno de dichos elementos, sobre todo cuando se trata de un juego 
simple. Sin embargo, ello significaría que tendría que copiar la salida de la 
VDU a un papel a mano, lo que constituye una tarea tediosa y bastante 
desaprovechadora de los recursos de una microcomputadora. El almace- 
namiento en casete se puede utilizar en lugar del almacenamiento en disco, 
pero es mucho más lento y trabaja en serie en lugar de hacerlo con un 
acceso aleatorio. Lo que ello significa es que un disco permite una 
utilización casi instantánea de cualquier dato o programa almacenado en 
cualquier lugar del disco, mientras que una casete ha de ser objeto de 
búsqueda en la secuencia de octeto a octeto, desde el principio hasta el 
punto correcto. De este modo, si estuviera acostumbrado a almacenar los 
datos para sus juegos en cintas C60, podría tardar media hora en 
encontrar los datos correctos, mientras que un tiempo de 5 segundos se 
consideraría demasiado largo para discos. 

Por supuesto, el Spectrum dispondrá de Microdrive, que es muy 
probable que ya esté disponible cuando se edite este libro. Aunque 
esencialmente se trata de un sistema basado en cinta, la unidad Microdrive 
realizará su función de forma muy similar a como lo hace una unidad de 
disco normal. Si puede conseguir disponer de una unidad de disco o 
Microdrive, será preferible que trate de conseguir dos de ellas, puesto que 
con dos unidades se le facilitará la copia de discos y el empleo de disco de 
programa y de discos de datos en unidades separadas. Con una sola 
unidad de disco, tendría que mantener todos los datos para un programa 
particular en el mismo disco o tendría que cambiar los discos mientras se 
está ejecutando el programa lo que no constituye una buena costumbre 
aunque sea habitualmente posible. 

Sin embargo, la mayoría de los poseedores de microcomputadoras no 
pueden conseguir unidades de disco, por lo que supondremos en el resto 
de este capitulo que la configuración de que se dispone es una microcom- 
putadora, una grabadora de casete y una impresora. Para el Spectrum ello 
significa tener también un interfaz xentronics o RS232 para controlar una 
impresora de rueda de margarita o matriz de puntos sofisticada, puesto 
que la impresora de Sinclair no es realmente adecuada para una salida 
atractiva que sea legible por los jugadores, aunque sea excelente para uso 
general. 

El diseño de su juego de PBM puede ser idéntico al de una aventura 
normal para microcomputadora, con la salvedad de que la salida debe ir a 
una impresora así como a, en lugar de, su pantalla de televisión. La 
programación real dependerá de la sintaxis del BASIC del interfaz que esté 
utilizando. Si está trabajando con una impresora de Sinclair, o el interfaz 
de que dispone admite las órdenes de Sinclair, lo único que hay que hacer 
es sustituir con LPRINT a PRINT. Si el juego tiene salida de gráficos o 
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una visualización en pantalla compleja o interesante, tendrá que utilizar 
COPY que efectúa la impresión, a través de la impresora, de una copia de 
lo que se visualiza en la pantalla. Sin embargo, esta característica 
funcional podría no ser viable con varias impresoras, con lo que puede ser 
que tenga que volver a diseñar la salida como una serie de órdenes 
LPRINT. Aunque sea mucho más tedioso, ello le proporciona más control 
sobre la salida. En consecuencia, si la salida impresa para cada jugador es 
esencialmente la misma con unas pocas variaciones, la orden LPRINT 
permitirá que se efectúen estos cambios en la salida impresa mientras que 
la visualización en pantalla puede seguir siendo la misma. 

Aunque sea posible tener un PBM que sea exactamente igual a una 
aventura ordinaria para microcomputadora, no resultará un juego de 
PBM muy satisfactorio. Á muy pocas personas les gustaría esperar dos 
semanas para conseguir una copia impresa de una visualización idéntica a 
la que podrían conseguir ejecutando el juego en su propia microcomputa- 
dora, sobre todo si cambia radicalmente de un turno de juego a otro. 
Ciertamente no sería muy divertido seguir intentando órdenes diferentes, 
tales como GOLPEAR PUERTA, DESTROZAR PUERTA, ROMPER 
PUERTA, etc., para dos semanas solamente para obtener un resultado de 
“nada sucede” cada vez. 

Por consiguiente, el diseño de una aventura de PBM debe tener, al 
menos, dos diferencias con respecto a la aventura normal. En primer 
lugar, se le debe permitir al jugador introducir instrucciones muy comple- 
jas, en lugar de órdenes simples de una sola palabra y en consecuencia, la 
salida debe ser compleja, y ha de cambiar notablemente en cada turno de 
juego. No importa que parte de la salida no sea significativa en lo que 
respecta a la ejecución del juego, tal como descripciones complicadas de 
localizaciones; lo que realmente importa es que exija un esfuerzo mental 
por parte del jugador. Una parte considerable de la diversión de una 
aventura PBM implica extraer de dichas descripciones complejas exacta- 
mente aquellos bits de información que sean importantes y que exijan una 
respuesta. 

Por ejemplo, en una aventura normal para microcomputadora, la 
salida en una posición especifica podría ser: 


Ve un recinto lleno de telarañas. Hay una gran araña en el techo. 


La descripción no puede ser mucho más larga que la anterior debido a las 
limitaciones en la capacidad de memoria. Puesto que dichas limitaciones 
se pueden suprimir por un maestro (“master”) de juegos de PBM, la 
descripción podría ser tan compleja como la siguiente: 


El recinto está lleno de polvo. En una esquina hay un cubo vuelto 
hacia arriba. El techo y una de las paredes están llenos de telarañas y 
varias arañas pequeñas se deslizan a través de los hilos. Hay un charco 
de líquido verdoso en el centro del recinto, en el que flota un 
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fragmento de pergamino. Se huele ligeramente a ácido en la habita- 
ción, sobre todo cerca de una acumulación de telarañas. Débilmente en 
la distancia se oye un sonido como de piedras cayendo por un 
acantilado. 


Ante dicha descripción, el jugador no sabe cuál de los elementos 
citados son importantes y cuáles no. Por consiguiente, debe escribir 
órdenes que tengan en cuenta el mayor número posible de las circunstan- 
cias. Sabemos que hay una gran araña en el núcleo principal de la telaraña 
y que el sonido distante es realmente una banda de orcas que descienden 
por el acantilado porque se han percatado de su presencia. Sin embargo, el 
jugador puede decidir ignorar la telaraña y el sonido y por el contrario, 
investigar el charco, el olor, las arañas pequeñas, el cubo, el polvo o el 
pergamino. Si lo hace así, la araña dará un salto y las orcas atacarán 
finalmente por detrás. 

Dos formas de elaborar dicha salida compleja en su juego son: 
desarrollar grandes bases de datos descriptivas o tener rutinas de “descrip- 
ción aleatoria”. El primer método no implica nada más de lo que ya 
hicimos cuando concebimos la sección de enigma de Camelot. Para cada 
posición, escribimos una descripción y la almacenamos como una rutina 
en la memoria RAM para ser objeto de llamada cuando el jugador llegaba 
a la posición correspondiente. La única diferencia que necesitamos 
efectuar es almacenar la descripción en medios magnéticos (en nuestro 
caso, casete). El Spectrum nos proporciona dos formas de hacer esta 
operación. Una forma es utilizar “MERGE” y la otra es utilizar la 
configuración “SAVE cadena DATA nombre del array()”. 

En el primer caso, describimos nuestro programa para aplicar 
LPRINT a una descripción utilizando los datos conservados como un 
programa aparte. La descripción podría retenerse como una serie de 
sentencias LPRINT o PRINT, o como sentencias DATA que han de ser 
objeto de lectura y luego manipularse o como cadenas o arrays de cadena 
que han de ser objeto de manipulación. Para tomar el ejemplo más 
sencillo, tendríamos un programa que acepta las instrucciones del jugador 
y que, a continuación, ha de imprimir una descripción de la siguiente 
posición. Supongamos que el programa utiliza una rutina que comienza 
en la línea 7000 para realizar la impresión de esta descripción. Entonces, el 
programa necesita llamar a la siguiente rutina antes de que se llame a la 
rutina existente en 7000: 


5999 REM RUTINA PARA ENCONTRAR Y CARGAR UNA 
DESCRIPCION 

6000 REM BUSQUEDA DE LA RUTINA CORRECTA 

6010 PRINT “Sírvase colocar la cinta de posición en la grabadora y 
pulse la tecla PLAY” 

6020 IF POSICION = 1 THEN MERGE “CASTILLO” 

6030 IF POSICION = 2 THEN MERGE “RECINTO” 


206 


6040 IF POSICION = 3 THEN MERGE “PANTANO” 


6100 GOSUB 7000 


La rutina le pide que ponga la cinta correcta en la grabadora de casete 
y luego, se realiza la búsqueda y la fusión (MERGE) del programa con el 
nombre apropiado. Cada uno de los programas con nombre que podría 
ser objeto de búsqueda estará en las líneas 7000 a 7999 y la numeración de 
las líneas para la totalidad debe ser idéntica. Ello es así porque un 
programa que sea objeto de fusión (MERGE) solamente borrará las líneas 
con números idénticos a los existentes en la rutina que fue objeto de tal 
fusión, por lo que podrían producirse errores si una descripción tuviera 
más números de línea que las demás. 

Una descripción típica podría ser similar a la siguiente: 


7000 REM CASTILLO 

7010 LPRINT “Ve un gran castillo negro” 

7020 LPRINT “Un murciélago está reboloteando alrededor de una 
torre” 

7030 LPRINT “Sobre la puerta se enarbola una bandera que lleva el 
emblema de un cuervo rojo sobre un campo verde” 

etc. 


Si dicha descripción no tiene ninguna significación para el juego, con 
solamente un colorido local, entonces la rutina objeto de fusión no 
necesita ser más que una lista de sentencias LPRINT. Sin embargo, cada 
posición diferente presumiblemente tendrá su propia característica de 
diseño, tales como la araña y las orcas en el ejemplo anterior. En 
consecuencia, estas rutinas deben transmitir también valores a la rutina 
principal en el programa que ha efectuado la llamada de la descripción. La 
clase de información que se precisará en la misma que se utilizaba en los 
capítulos anteriores para describir monstruos, ambientes y objetos (esto 
es, valores para todas las variables en el programa que caracterizan a esa 
posición y ante las que el protagonista del jugador podría efectuar una 
interacción. Incluirían valores de combate, listas de posibles objetos y 
códigos para los efectos posibles, valores mágicos de monstruos y del 
ambiente, etc. 

También es posible elaborar subrutinas, en la configuración de cada 
recinto, de modo que las diferentes posibilidades se presenten por sí 
mismas en diferentes visitas. Por ejemplo, la rutina del castillo podría 
tener una rutina que determinara si la puerta está cerrada o abierta (y 
pasando consiguientemente un valor al programa principal) o bien, una 
rutina que variara la descripción, dependiendo quizá de las capacidades de 
búsqueda del jugador o una rutina que determinara, de forma aleatoria, si 
el murciélago ataca al jugador. 

Asimismo, es viable que una rutina objeto de fusión (MERGE) en esta 
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forma efectúa la llamada y fusión de otra, bien sea como una subrutina de 
ella misma, bien sea sustituyéndola. Si utilizamos este último método, 
debemos indexar nuestras cintas de forma muy cuidadosa y cerciorarnos 
de que la solicitud interactiva en cada llamada de fusión (MERGE), que 
pide al maestro del juego que introduzca una casete, especifica exactamen- 
te la casete correcta de una forma no ambigua. Cada descripción requiere 
un nombre singular, debiendo escribirse cada nombre en la casete, 
debiendo tener cada casete su propio nombre o número y preferiblemente, 
debiendo existir un indice del conjunto completo. 

Le puede resultar sorprendente que una rutina de localización tal como 
la del castillo anterior pueda ser deseable su fusión con otra que le borra. 
Un ejemplo característico sería una rutina de desplazamiento (bien sea 
una rutina de desviación o de transportador con carácter arbitrario) o 
bien, una rutina que obligue al jugador a desplazarse a una posición 
particular, tal como en el modo de retirada, por ejemplo, o siendo 
transportado por un águila gigante a su nido. Por ejemplo: 


7200 LET T = INT(RND+3) 

7210 IFR = 1 THEN LPRINT “Un águila gigante desciende y le 
transporta a su nido”: PRINT “Sírvase introducir la cinta Nl y 
pulse la tecla PLAY””: MERGE “NIDO” 

7200 REM RUTINA DEL NIDO 

7210 LPRINT “Está en un nido enorme y hediondo” 

7220 LPRINT “Hay tres huevos en el nido” 


El segundo método de almacenar y cargar posiciones descriptivas es 
menos versátil que el empleo de la fusión (MERGE) porque el programa- 
dor está limitado a cargar datos y no rutinas. Sin embargo, si solamente 
necesitamos almacenar descripciones, y no subrutinas de cualquier clase, 
entonces estas últimas se pueden mantener en arrays de cadenas. Una 
importante ventaja de este método con respecto al método de fusión es 
que no existe ninguna necesidad de que nos preocupemos acerca de la 
coincidencia exacta entre los números de línea. La operación de carga 
(LOAD) de un array de cadena que se haya salvaguardado con anteriori- 
dad solamente produce el borrado de cualquier otro array o variable de 
cadena en el programa con el mismo nombre. 

Este método se utilizará por las microcomputadoras sin la rutina 
MERGE u otra rutina de manipulación de ficheros del casete y se 
emplearía con frecuencia si el programa principal contuviera todos los 
valores, variables y rutinas interactivas. Se limita a cargar un array 
particular, que podemos llamar L$, con la información que las rutinas 
preexistentes utilizan para la salida. En el Spectrum BASIC, para guardar 
(SAVE) un array utilizamos “SAVE “CASTILLO” DATA L5$(”, y para 
su carga empleamos “LOAD “CASTILLO” DATA L$(0”. Utilizando un 
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array denominado L$ se ahorra una serie de octetos con la denominación 
“CASTILLO”. De este modo, podemos utilizar Órdenes prácticamente 
idénticas para efectuar la llamada de nuestros datos descriptivos en el 
programa, tal como: 


6020 IF POSICION = 2 THEN LOAD “CASTILLO” DATA L$0 


Ha de tenerse presente para asegurar que haya suficiente espacio para 
la carga que es probable que se necesite el más grande de los arrays 
guardados. Sin embargo, no necesitamos dimensionar (DIM) el array ni 
cambiar las dimensiones si los posibles arrays que sustituyan a L$() son de 
tamaños diferentes. Este método es, pues, más fácil de utilizar que el de 
fusión compleja, porque hay una menor posibilidad de cometer errores. 
Esta facilidad se ““paga” con la relativa falta de versatilidad. 

Las operaciones de guardar (SAVE) y de carga (LOAD) de datos y 
rutinas a partir de una casete se puede utilizar en las aventuras ordinarias 
para microcomputadoras pero siempre llevan consigo un retardo conside- 
rable. En consecuencia, pocas aventuras interactivas utilizan este método, 
salvo con la división de la aventura en una serie de grandes programas 
separados, que suelen transmitir datos desde uno de ellos al siguiente. Sin 
ninguna relación entre las aventuras en esta forma, pueden parecer que no 
son diferentes de las aventuras independientes. 

El segundo método de crear descripciones complicadas requiere más 
esfuerzo mental antes de la codificación, pero menos codificación real. En 
consecuencia, requieren menos memoria, almacenamiento y tiempo. La 
técnica implica la mezcla de las descripciones significativas que son 
especificas de las posiciones con una descripción no significativa determi- 
nada de forma aleatoria. Hemos visto cómo se puede realizar dicha 
operación en el Capítulo 7, en donde se realizó un modo de ““conversa- 
ción” de carácter significativo y aleatorio. 

El problema a resolver es cómo adaptar las descripciones aleatorias a 
las descripciones fijas de una manera que tenga sentido y también en 
forma compatible con el entorno y la trama circundante. Es necesario 
concebir un sistema de señalización de modo que a todas las posiciones se 
les de un cierto tipo y que cada tipo pueda llamar a frases aleatorias 
típicas. Por ejemplo, un tipo de posición puede ser “el Castillo”. Cada 
castillo diferente tendrá su propia descripción singular y rutinas asociadas 
que puedan modificar el protagonista del jugador. Sin embargo, todos los 
castillos llamarían rutinas que establecieran descripciones aleatorias de 
detalles adicionales con el empleo de unidades como “las torres”, “las 
almenas”, “el tipo de piedra”, “la forma de las ventanas”, “el número de 
puertas”, “clases de moradores”, “grado de dilapidación”. 

Esta clase de aleatorización puede hacerse también más significativa, 
tal como cuando se dispone la producción de encuentros típicos. Lo 
mismo que en una aventura interactiva, algunas posiciones tienen ciertos 
tipos de monstruo y de tesoro, por lo que en un juego de PBM se pueden 
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elaborar conjuntos de rutinas que no solamente añadan una descripción 
circunstancial sino también una narración circunstancial. Las cosas que 
vayan a suceder alrededor y en relación con el protagonista del jugador, 
aunque no tengan significación estructural, se añadirán al atractivo del 
juego (lo que será agradable para quienes juegan la aventura porque se 
sienten como protagonista de una novela fantástica) y se pueden dar 
pistas, sugerencias y plantear problemas aparentes (para quienes están 
más interesados por descubrir todos los aspectos de las posibilidades de un 
juego). 

Todos los sistemas de esta naturaleza tienen tres partes básicas. En 
primer lugar, hay las unidades descriptivas que constituyen la base de la 
construcción del texto. En segundo lugar, hay los sistemas de codificación 
que traducen los diferentes tipos de posición en diferentes descripciones 
posibles. Y en tercer lugar, existen las mini-rutinas que sirven de apoyo a 
dichas descripciones con sucesos adecuados. 

Para poner de manifiesto la forma en que dicho sistema podría 
trabajar, construyamos un juego con los simples criterios siguientes: 


1. Hay tres tipos de posición: Por debajo del agua, en la superficie del 
agua y a bordo del barco. 

2. Hay cuatro parámetros de monstruos: Capacidades de combate, 
conocimiento de secretos, tipo de movilidad y modo de comunicación. 


El juego tendrá, pues, un conjunto de descripciones cidificadas en la 
forma adecuada para una, dos o los tres tipos de posición, tendrá también 
un conjunto de estructuras de eventos, constituidas por los componentes 
descritos en los Capítulos 2 y 3, con una codificación similar, y finalmente, 
un conjunto de rutinas cuyos códigos emparejan los códigos de descrip- 
ción y de sucesos para ponerlos juntos en un monstruo para esta posición, 
cuyos valores en todos los parámetros se adapten al código elegido. 

Supongamos que el código 1 era "debajo del agua”, el código 2 fuera 
“en la superficie” y el código 4 fuera “a bordo del barco”; entonces, las 
descripciones y los eventos podrían tener códigos del 1 al 7 con lo que se 
indicaría qué tipo de posición era la adecuada. El código 3 es, a la vez, 
debajo y en el agua, el código 6, es en la superficie y a bordo del barco y 
así sucesivamente. Todas las estructuras de los eventos y los parámetros 
del monstruo se codificarían de forma análoga. De este modo el paráme- 
tro del “modo de comunicación podría tener los valores y los códigos 
posibles siguientes: 


Valor Descripción Código 
hablando 

gesticulando 

batiendo el agua con aletas 
cantando 

soplando burbujas 
movimientos acrobáticos 


Dun E Y nun — 
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Todos los demás parámetros se codificarían de una forma similar, con 
todos los valores posibles del parámetro representando los aspectos 
posibles de un monstruo con una descripción verbal equivalente y se 
codificarán para asegurar la compatibilidad entre la posición elegida, el 
evento y todas las características del monstruo. Por lo tanto, si elegimos, 
de forma aleatoria, como nuestra posición a “flotando en medio de una 
maraña de algas”, ello tendría el código 2, por lo que el monstruo que 
estaba en este lugar podría ser capaz de comunicar por medio de 
cualquiera de los siguientes medios: hablando, gesticulando, batiendo el 
agua con aletas y cantando (pero no mediante movimientos acrobáticos ni 
soplando burbujas). 

De esta forma, se elaboraría una descripción de posición que fuera 
esencialmente aleatoria, no concebida por el programador, pero singular- 
mente configurada y llena de significación para el jugador porque los 
elementos eran compatibles en su totalidad y proporcionan un nuevo 
evento para que el jugador de una respuesta. La incorporación al aspecto 
descriptivo serían posibilidades codificadas de forma análoga. Por ejem- 
plo, el juego puede elaborarse sobre la premisa de que las criaturas en la 
superficie del ¡agua eran hostiles por lo general (por consiguiente, la 
variable “enemigo” se hace igual a —6, pero aquellas criaturas que 
puedan hablar suelen ser amistosas ““por tanto, una posibilidad de que la 
variable “enemiga” será modificada se indicará por medio de un valor 
comprendido entre 1 y 9. El jugador será capaz de asimilar estas 
tendencias a través de una interacción anterior, por lo que será capaz de 
reaccionar a esta nueva situación con un grado de conocimiento pero 
también con una gran incertidumbre. 

La única limitación para el diseñador de un juego de PBM de esta 
naturaleza es el tiempo de que dispone para crear la sucesión original del 
programa. Cuanto más tiempo tengamos, tanto más podemos incorporar 
al juego con la posibilidad de que todos los parámetros estén codificados. 
Todos los parámetros pueden tener, por sí mismos, parámetros. El grado 
de posible complejidad es inmenso y dicha complejidad puede ser muy 
similar a la de la vida real y estar llena de significación, lo que constituye 
una buena solución de compromiso entre las aventuras puramente 
aleatorias y netamente determinadas que se ejecutan exclusivamente en 
microcomputadoras. 
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